Поскольку вы сказали, что платформа и язык не имеют значения ...
Если вам нужна стабильная производительность, настолько высокая, насколько позволяет исходный носитель, я знаю, что единственный способ сделать это в Windows - перекрывающиеся последовательные операции чтения без буферизации в ОС. Вероятно, вы можете получить несколько гигабайт / с с двумя или тремя буферами, кроме того, в какой-то момент вам понадобится кольцевой буфер (один модуль записи, 1+ читателей), чтобы избежать копирования. Точная реализация зависит от драйвера / API. Если происходит копирование памяти в потоке (как в ядре, так и в пользовательском режиме), имеющем дело с вводом-выводом, очевидно, что чем больше буфер для копирования, тем больше времени тратится на это, а не на ввод-вывод. Поэтому оптимальный размер буфера зависит от прошивки и драйвера. На Windows хорошие значения, которые нужно попробовать, кратны 32 КБ для дискового ввода-вывода. Буферизация файлов Windows, отображение памяти и все такое добавляет накладных расходов. Хорошо только в том случае, если выполняется одно или несколько одновременных чтений одних и тех же данных в режиме произвольного доступа. Так что для чтения большого файла последовательно один раз, вы не хотите, чтобы ОС что-то буферизировала или делала какие-либо memcpy. При использовании C # также существуют штрафы за вызов в ОС из-за маршалинга, поэтому код взаимодействия может нуждаться в некоторой оптимизации, если вы не используете C ++ / CLI.
Некоторые люди предпочитают бросать аппаратные средства при проблемах, но если у вас больше времени, чем денег, в некоторых сценариях можно оптимизировать вещи для повышения производительности в 100-1000 раз на одном компьютере уровня потребителя, чем на компьютерах с корпоративной ценой 1000. Причина в том, что если обработка также чувствительна к задержке, выход за пределы использования двух ядер, вероятно, добавляет задержку. Вот почему драйверы могут выдавать гигабайты / с, в то время как корпоративное программное обеспечение останавливается на мегабайтах / с к тому времени, когда все это сделано. Что бы ни делали отчеты, бизнес-логика и подобное корпоративное программное обеспечение, вероятно, также можно выполнить со скоростью гигабайт / с на двухъядерном потребительском процессоре, если вы пишете так, как вы вернулись в 80-е годы при написании игры. Самым известным примером, который я слышал о таком подходе ко всей их бизнес-логике, является биржа форекс LMAX, которая опубликовала часть своего кода на основе кольцевого буфера, который, как говорили, был вдохновлен драйверами сетевых карт.
Забывая всю теорию, если вы довольны <1 ГБ / с, одна возможная отправная точка для Windows, которую я нашел, - это просмотр источника readfile из winimage, если вы не хотите копаться в примерах sdk / driver. Может потребоваться исправление исходного кода для правильного расчета производительности на скоростях SSD. Экспериментируйте также с размерами буфера.
Многопоточные коммутаторы / h и / o перекрываются (порт завершения) ввода-вывода с оптимальным размером буфера (попробуйте 32,64,128 КБ и т. Д.) Без использования буферизации файлов Windows, по моему опыту, дают лучшие результаты при чтении с SSD (холодные данные) при одновременной обработке (используйте / a для обработки Адлера, так как в противном случае он слишком привязан к процессору). </p>