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

[Igors]

Добрый день

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

Спасибо

[Авварон]

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

[Igors]

Ну "одинаковые кадры" хотя и возможны но редко. А вот те или иные данные (в разных кадрах) повторяются очень часто.

"Линк" ссылается на место в файле, где лежит таг "данные". Так можно будет переиспользовать кадры, записанные ранее

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

[Авварон]

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

[deMax]

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

[Igors]

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

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

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

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

[Old]

Но вот скорость загрузки не только не возрастает, а возможно и наоборот, несколько упадет из-за частых seek'ов. А хотелось бы...

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

[deMax]

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

[Igors]

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

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

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

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

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

[deMax]

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

Я написал исходя из этого:

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

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

[Igors]

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

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

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

Если ваших данных меньше ..
Ваши данные влезают ..
Ваши данные не влезают ...

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

[Racheengel]

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

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

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

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

[Авварон]

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

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

[deMax]

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

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

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

[Igors]

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

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

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

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

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

Если это не древний хлам ..

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