Это не совсем ответ как таковой. Тем не менее, он должен дать вам идеи о том, как конкретно вы можете ускорить это
На первый взгляд, это делится на вероятности, параллелизм и размер патрона.
Если существует высокая вероятность того, что следующее чтение / запись будет найдено в большем фрагменте, то большой размер фрагмента будет повышением производительности. В свою очередь, не нужно продолжать сканирование диска.
Если вы используете SSD , вы, вероятно, можете загружать кучу Mbs (за раз) более производительным способом, чем блок по умолчанию 4k, который он, вероятно, использует.
Кроме того, по-видимому, это можно разбить на параллельные рабочие нагрузки ... Хотя на самом деле неясно, какие изменения вам понадобятся с самого начала.
Однако, если вы действительно хотите это быстро
- Иди и купи себе 32 гигабайта барана
- Создать унаследованный класс Stream или, что еще лучше, просто пользовательский класс
- Загрузите весь набор данных в память, разбитый на массивы кусков примерно в гиг.
- Использовать прямой доступ к указателю
- Использовать параллельные рабочие нагрузки
Если бы вы могли сделать это (и это умозрительно), вы могли бы ускорить это на много факторов быстрее. И за беспорядочную стоимость памяти в пару сотен долларов и кодирования на несколько дней.
Потрясающий комментарий от @ NPras
Вместо того, чтобы самостоятельно управлять кэшированием / разбиением оперативной памяти, вы также можете
хочу взглянуть на концепцию сопоставленного с памятью файла s и пусть ОС
управлять этим для вас
И из Управление отображенными в память файлами
![enter image description here](https://i.stack.imgur.com/TJYQy.png)