Должен ли я сжимать объекты С# в памяти для лучшей производительности?

У меня есть приложение (С#, WPF), которое отображает множество финансовых графиков с потоковой передачей живых данных с сервера. Данные, собранные в памяти, могут быть немного большими, и я не хочу хранить данные на диске.

Поскольку сами исторические данные не изменяются, а только добавляются, будет ли смысл хранить эти данные (которые хранятся в объекте коллекции) в каком-то сжатом формате?

Возможно ли, и может ли кто-нибудь порекомендовать ему хорошую практику, если так?

UPDATE

Некоторые примечания о производительности и компромиссе: Я знаю, что сжатие добавит задержку доступа к данным, но пользователю нужны только быстрые обновления при поступлении новых данных. При доступе к данным, которые уже были обработаны (например, для изучения или повторной визуализации), он не требует быстрого ответа.

Ответ 1

Сжатие и распаковка сделает ваше приложение медленнее, поэтому для производительности (скорости) это не очень хороший вариант. Сжатие полезно только в том случае, если вас беспокоит доступная память. Может быть проще хранить/заменять данные в временную папку.

Ключом к производительности является измерение. Выполняйте действия только тогда, когда вы свернули цифры.

Ответ 2

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

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

Сжатие может выполняться с помощью классов System.IO.Compression и довольно легко. Однако эти классы не очень хорошо работают, поэтому вы можете также рассмотреть альтернативу третьей стороны, такую как DotNetZip.

Ответ 3

Это компромисс между производительностью и объемом памяти, а также зависит от используемых вами структур данных. "Общее" сжатие (например, gzip, кодирование длины и т.д.) Не имеет смысла для многих типов данных.

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

Ответ 4

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

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

Учитывая все это,.NET предоставляет пространство имен System.IO.Compression для выполнения сжатия gzip. Если вам нужно сжатие, я бы начал с поиска там.

Ответ 5

Если вы захотите его самостоятельно закодировать, существуют пространственно-эффективные структуры данных, которые не требуют использования декодирования/декомпрессии. Стив Ханов описывает Succinct Data Structures в своем последнем сообщении в блоге. Его пример - краткий трюк, но ничто не мешает вам представлять другие объекты и структуры. Он приводит несколько альтернативных вариантов.

Очевидно, что это не готовое решение. Вам нужно будет решить, стоит ли пытаться построить и протестировать сжатое представление.