Russian Qt Forum

Добрый день

В файл пишутся данные "кадр за кадром". Может запишем всего 1 кадр, но может и 1000 и более. Известно что многие данные "статичны" т.е. одни и те же для всех записываемых кадров. Конечно "писать все и всегда" надежно, а главное - работы меньше (обычно в таких случаях приплетается "преждевременная оптимизация"). Но все же это не есть хорошо. Ну так как бум оптимизировать?

Спасибо

Тагами. Каждый фрейм снабжен тагом (типом) "полный фрейм" или "повтор кадра".
Есть более сложный вариант с "хардлинками", когда есть два тага "данные" и "линк". Таг "данные" хнанит после себя кадр. "Линк" ссылается на место в файле, где лежит таг "данные". Так можно будет переиспользовать кадры, записанные ранее (но надо где-то отдельно хранить мапу ид/хэш кадра -> место в файле)

Ну "одинаковые кадры" хотя и возможны но редко. А вот те или иные данные (в разных кадрах) повторяются очень часто.
Да, это решает одну задачу - резко сокращает размер файла данных. Но вот скорость загрузки не только не возрастает, а возможно и наоборот, несколько упадет из-за частых seek'ов. А хотелось бы...

Ладно, задам вопрос - файл пишется поточно или на момент записи известны все фреймы?

Это видеонаблюдение - где на фоне статичной картинки что то мелькает, и можно статичную картинку поксорить с остальными кадрами, а потом пожать черный фон в "пару килобайт"?
(раз в час обновлять с учетом день-ночь; дождь снег молнии правда заспамят)

Кадр за кадром, следующий неизвестен. Но для многих данных известно будут ли они меняться (от кадра к кадру) или нет.

Ну почему обязательно "видео"? Это пока данные для рендера, до видео еще далеко :) Данные обычные (структуры, контейнеры и.т.п.)

Это почему? Ничего она не упадет. Данные кадра нужно читать один раз, а дальше шарить их в памяти, а не сикать и перечитывать.

Для начала нужно вообще проверить что это узкое место, сикать с винта. Я с винта "сикал" по гигабайтам данных, загружая мегабайты, работало более чем достаточно(это еще винт не ssd был).
p.s. а то будет экономия на спичках, хитрый кэш в памяти(если вдруг ваш файл в озу не уместиться - хотя сейчас и по 32Гига памяти есть).

Ой спасибо, кэп, что Вы это объяснили! А то сидим тут, и вот просто от нечего делать выдумываем задачи которые не очень-то и нужны  :)
Приложение-читатель отслеживает кол-во используемой памяти своими средствами. Если памяти не хватает, то кэши должны быть выброшены и данные должны повторно грузиться с диска (хотя это и медленнее)

Данные НЕ константны, после загрузки они могут меняться всяко-разно (хотя загружалось одно и то же).

Я написал исходя из этого:
То что скорость рендомного доступа раз так в 100 ниже для обычного HDD и так понятна, но может у вас будут редко промахи мимо кэша винта. Протестить для начала неплохо бы, а то я тоже пару раз занимался оптимизацией, а потом понял что сэкономил на спичках.
Если ваших данных меньше чем кеш винта - забить на оптимизацию, линукс кэширует винт(и ваших данных меньше свободного озу) - аналогично.
Ваши данные влезают в ОЗУ - загрузить все в ОЗУ.
Ваши данные не влезают в ОЗУ, а вот тут можно пообсуждать и немного подумать.

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

Так вот, давайте примем без всяких доказательств что задачу решать НАДО. Возможно Вы в 100 раз умнее меня, но свою задачу я знаю в 100 раз лучше, поэтому мне виднее. И вот что
А почему Вы думаете что (примерный) объем данных известен? Для порядочных задач это обычно не так, и способность приложения обрабатывать большие объемы данных (пусть и медленнее) и является "показателем класса". А то тупенько вылететь по std::bad_alloc всякий может.

Я бы был ооочень осторожен в таких высказываниях :)

Есть один маленький противный нюанс: никто заранее не знает, сколько ОЗУ на целевой машине, какой винт, какая ось, ну и еще там фиг знает, какие условия.

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

Ну так чем два предложенных решения не устраивают?

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

Мы то не знаем объемы данных, может это пару метров(на которые можно положить seek) , а может и эксабайты (где QMap уже не поможет и придется БД использовать или еще что более хитрое).

Сказать что-то в тему - еще не решение

Вот, товарищ понимает. Добавлю что часто только такими "маленькими подробностями" и отличается профессиональный софт от бесплатного.

Опять гоняем порожняк - винт, озу (шмотье, музон)

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


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

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

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

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

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