В первую очередь при чтении/записи нужно проверять чтение/запись.
Что в деталях скрывается за "streamReader.ReadLine()" я не знаю, но я бы полез узнать. Вряд ли, конечно, он обращается к файлу построчно, но всё равно это первое что я бы копал. Возможно читал более крупными чанками (это банально зависит от ssd/nvme ssd/hdd).
Если говорить про CPU оптимизации, их нужно максимально изолировать от остального окружения. Банально выключить видео в youtube)) Ну и конечно прогонять тесты на уже загруженных данных. Тогда будет понятно, что меряем и что нужно оптимизировать. А вот дальше уже начинается самое интересное) Но все cpu-side оптимизации могут про сильно пролететь по сравнению с одной оптимизацией чтения.
Будет время может помогу с более дельными советами.

такое вроде уже все сделано,  паралельный парсинг черех  TPL.Dataflow и парсинг float через обычное API и Span.

авх/ссе правда не решился еще пробовать.
паралелизация парсинга ускорила с 44 сек до 16 сек.
интересно можно ли дальше)

cpu side нужен в любом случае если ты хочешь извлечь максимум (по сути на парсинг строки ты будешь раз в ~5 меньше времени тратить).  Читать построчтно - не надо

предлагаешь все прочитать в начале и засунуть в один string?

ну чанками же, в каждом по много строк для параллельной обработки, размер чанка будет сложно настроить :)

буфер, упреждающее чтение, конечный автомат

если сразу все прочитать - цпу будет без дела сидеть пока ио работает

если по одной строке - то еще хуже

если IO будет медленее парсинга, то лучше чем скорость IO сделать не получится в любом случае, а вот изгадить - легко

если решишься все таки на симдах делать - могу помочь как-нибудь)

ok =) спасибо.
не читать построчно - звучит как идея которую стоит попробовать =)

Видел как-то костыль в котором кусками вычитывали XML тоже из рассчёта "мы сейчас побольше прочитаем и будет ок". В итоге оно работало довольно тормозно и были проблемы с разбором самого файла и с тем, что над ним потом можно было сверху делать (т.к. само приведение в XmlElement уже довольно дорого стоит, а когда его ещё и над каждым кусочком делают...). Самым производительным вариантом в итоге стало выкинуть эту чудо-оптимизацию =)

хмл и жсон парсинг очень плохо параллелятся :)

Gpl и не поддерживается

Да там и параллелить не надо было. Надо было просто читать достаточно большие файлы не убивая при этом весь хост одним действием.

не всегда это возможно, иногда файлы слишком большие, иногда они буферно из сокета вылазят

mmap лучше всего, имхо

Смапил файл в память — и дальше броди по нему как по спану

+

Хьюстон, у нас проблема: размер и индекс в спане 32-битный