Запись повторяющихся данных в файл

[Racheengel]

Или для прототипа. Если это не древний хлам то у винта кэш от 32Мб(и скорее всего винт ssd), и озу >4Gb.
Можно еще системные требования написать.

Системные требования К ЧЕМУ? К неизвестно какому железу, которое, может быть, еще под ХР работает, и стоит в запыленном цехе, а винты меняются раз в месяц? Увы, мир индустрии отличается от лабораторий чуть менее, чем на 100%...

Мы то не знаем объемы данных, может это пару метров(на которые можно положить seek) , а может и эксабайты

Ну так в этом и задача - сделать решение, которое не будет зависеть от объемов.

По теме: а можно применить инкрементальное сжатие? Т.е. сохранять только разницу между кадрами. Если это типизированные модели данных, то каждый элемент будет либо содержать "свои данные", либо маркер "возьми последние загруженные" (это очень упрощенно, конечно - но мы примерно так и делали).

[Igors]

По теме: а можно применить инкрементальное сжатие? Т.е. сохранять только разницу между кадрами. Если это типизированные модели данных, то каждый элемент будет либо содержать "свои данные", либо маркер "возьми последние загруженные" (это очень упрощенно, конечно - но мы примерно так и делали).

Читатель рендерит кадр за кадром пока они не кончатся. Когда кадр отрендерен - все структуры данных удаляются и заново загружаются для след кадра. Возможно кадры будут одинаковы (редко), но могут и не иметь ничего общего. Сбегать посмотреть "что там дальше" нереально. Поэтому откуда возьмутся "уже загруженные"?

Также неясно: ну вот хорошо, десериализовали объект из файла, теперь он в памяти. Я не вижу возможности "воспользоваться им  в дальнейшем". Во-первых он может быть изменен после загрузки (практически наверняка). Во-вторых никто не обещал что он копируемый/перемещаемый (обычно нет). А вводить какие-то требования/ограничения для огромного числа объектов в угоду чисто "локальной оптимизации" - об этом не может быть и речи.

[Old]

Также неясно: ну вот хорошо, десериализовали объект из файла, теперь он в памяти. Я не вижу возможности "воспользоваться им  в дальнейшем". Во-первых он может быть изменен после загрузки (практически наверняка). Во-вторых никто не обещал что он копируемый/перемещаемый (обычно нет). А вводить какие-то требования/ограничения для огромного числа объектов в угоду чисто "локальной оптимизации" - об этом не может быть и речи.

В памяти нужно хранить сырые прочитанные данные, а не готовые объекты.
Прочитали блок данных - сохранили его в кеше. Дальше десериализовали из этого блока - объект. Пошли дальше по файлу... встретили тег повтора, залезли в кеш блоков. Если нашли такой блок - десериализовали из этого блока еще один объект, не наши - загрузили блок из файла и сохранили его в кеше.