Самый быстрый способ десериализации объектов из огромного двоичного файла

Question

Итак, сценарий выглядит следующим образом: у меня есть файлы размером в 2 Гбайт двоичных сериализованных объектов, у меня также есть индексный файл, который содержит идентификатор каждого объекта и их смещение в файл.

Мне нужно написать метод, в котором задан набор идентификаторов десериализации их в память. Производительность является самым важным эталоном, и сохранение разумных требований к памяти является вторым.

Использование MemoryMappedFile похоже на путь, однако я немного не уверен, как обрабатывать большой файл. Я не могу создать MemoryMappedViewAccessor для всего файла, так как он настолько велик. Могу ли я одновременно открыть несколько разных MemoryMappedViewAccessor из разных сегментов, не затрагивая слишком много памяти, в таком случае, насколько большими должны быть эти сегменты?

Представления могут храниться в памяти некоторое время, если данные доступны много, а затем утилизировать

А может быть, наивный метод должен был бы заказать объекты быть извлечена путем смещения и просто вызовите CreateViewAccessor для каждого смещения с небольшой буфер. Другим было бы попытаться выяснить наименьшее количество различных MemoryMappedViewAccessor и их размер. Но я не уверен в накладных расходах при создании CreateViewAccessor и о том, сколько места вы можете безопасно получить за один раз. Я могу провести некоторое тестирование, но если у кого-то есть лучшая идея ... :)

Я предполагаю, что еще один способ - разбить большой файл данных на несколько, но я не уверен, что в этом случае все будет хорошо. ..

Answer 1

В каком хранилище находится файл? Обычный жесткий диск или SSD? В случае нормального hdd вы должны минимизировать время поиска, поэтому вам может потребоваться заказать ваш доступ по смещению.

Я думаю, что наличие больших сегментов с отображением памяти не требует большого количества ОЗУ. Они занимают только адресное пространство, так как они могут быть защищены самим файлом. Таким образом, большая часть используемой ОЗУ - это кэш ОС.

Из того, что я слышал, асинхронный ввод-вывод с использованием I/O Completion Ports является самым быстрым, но я еще не использовал их сам.

Answer 2

Мой вопрос к вам, почему у вас есть 2 3 ГБ файла сериализованных объектов? Это всегда будет проблемой производительности, загружающей это.
Вам действительно нужно обрабатывать всю эту информацию сразу? Лучшим подходом может быть какая-то база данных, которую вы будете использовать для запроса необходимых вам элементов, когда это необходимо, и перестроить их в этот момент. Можете ли вы предоставить дополнительную информацию о том, какие данные вы храните и как используете. Мне кажется, что вашему дизайну требуется небольшая работа.