C++, что библиотека сжатия в оперативной памяти?
Я уже погуглил для сжатия в оперативной памяти и нашел довольно много библиотек этим offert эта функциональность. zlib, кажется, широко используется - но это также, кажется, довольно старо. Я спрашиваю здесь, существуют ли более новые, лучшие альтернативы.
Данные, которые я хочу сжать в оперативной памяти, являются memorypools с размером нескольких мегабайтов (2-16 МБ), и каждый из тех блоков содержит данные двух различных структур, а также некоторых массивов указателей. в блоках нет никакого особого порядка на структуры и массивы, они просто выделяются за другим, когда приложение должно создать такой элемент.
Какой lib сжатия Вы предложили бы для этого? сжатие и выполнение распаковки (оба) более важны, чем качество сжатия.
Также - по причинам сжатия - было бы лучше иметь отдельные пулы для двух различных структур, а также массивов, таких, что каждый блок данных, который будет сжат только, содержит один вид данных?
Это - первый раз, когда я намереваюсь использовать сжатие в оперативной памяти, и я знаю, что мой вопрос является, возможно, слишком общим для предоставления хорошего ответа - но каждая подсказка приветствуется!
Спасибо!
6 ответов
zlib - это хорошо. Доказанный, производительный и понятный многим. Это то, что я бы использовал по умолчанию в новой системе, как вы описываете. Ее возраст следует рассматривать как одно из величайших достоинств.
Для чего-то более современного, чем zlib, libbzip2, возможно, стоит взглянуть. Для совместимости он предоставляет интерфейс, похожий на zlib. Во многих случаях, он предлагает лучшее сжатие, но при стоимости производительности.
Для чего-то более быстрого, чем zlib (но которое не сжимает и ...) есть LZO.
.Если для вас важна скорость сжатия/декомпрессии, то вам следует взглянуть на LZO:
http://www.oberhumer.com/opensource/lzo/
По сравнению с zlib код меньше и проще в использовании.
.На современных операционных системах с менеджером виртуальной памяти делать это не имеет смысла. Вы создадите кучу байт, которые ни к чему не приведут, занимая место в адресном пространстве виртуальной памяти без всякой на то причины. Менеджер памяти не оставит его в оперативной памяти надолго, он заметит, что страницы, занятые блобом, недоступны, и подкачает его в файл подкачки.
Кроме того, вам придётся транслировать данные, если в нём есть указатели. Вероятность того, что вы сможете распаковать данные по тому же самому адресу виртуальной памяти, так что указатели все еще действительны, очень близка к нулю. В конце концов, вы сделали это, чтобы освободить пространство виртуальной памяти, дыра, которую раньше использовали данные, будет занята чем-то другим. Скорее всего, такая трансляция не будет тривиальной и займет много дополнительной памяти.
Если вы делаете это, чтобы избежать OOM, то посмотрите на поддержку операционной системой файлов mapped памяти и подумайте о переходе на 64-битный код.
.Я не знаю ничего более нового/быстрее, чем zlib... zlib прекрасно работает, несмотря на свой возраст. zlib's deflateInit() имеет аргумент, который позволяет вам обменять скорость сжатия на сжатый размер, так что вы можете поэкспериментировать с этим, чтобы найти настройку, которая лучше всего подходит для вашего приложения.
Вероятно, существуют C++ API обертки, которые вызывают для вас zlib C API, если вы хотите что-то "красивее"... или если нет, то это достаточно просто, чтобы написать свое собственное.
.Для компрессии данные имеют большое значение. Сжатие произвольных двоичных данных в памяти - это пустая трата времени, это сильно замедлит вашу производительность и, вероятно, в конечном итоге, увеличит использование памяти.
Если вам действительно необходимо иметь гораздо больше памяти, то вам следует обратить внимание на использование VirtualAlloc или sbrk для самостоятельного управления памятью. Таким образом, Вы сможете обращаться ко ВСЕЙ физической памяти, а не только к 2-4 гб.