Как найти хороший / оптимальный словарь для zlib 'setDictionary' при обработке данного набора данных? - PullRequest
17 голосов
/ 06 января 2010

У меня (огромный) набор похожих файлов данных. Набор постоянно растет. Размер одного файла составляет около 10К. Каждый файл должен быть сжат самостоятельно. Сжатие выполняется с помощью библиотеки zlib, которая используется классом java.util.zip.Deflater. При передаче словаря в алгоритм Deflate с использованием setDictionary, я могу улучшить степень сжатия.

Есть ли способ (алгоритм) найти «оптимальный» словарь, то есть словарь с общей оптимальной степенью сжатия?

См. Руководство по zlib

1 Ответ

12 голосов
/ 28 февраля 2010

Джон Рейзер объяснил на comp.compression :

Для словаря: создайте гистограмму коротких подстрок , отсортируйте по размеру выплаты (число вхождений, умноженное на число битов, сохраненных при сжатии) и поместите в словарь подстроки с самой высокой выплатой. Например, если k - длина самой короткой подстроки, которая может быть сжата (обычно 3 == k или 2 == k), то составьте гистограмму всех подстрок длины k, 1 + k, 2 + k и 3 + к. Конечно, есть некоторая возможность поместить эти подстроки в словарь, используя преимущества подстрок, перекрытия, коротких строк ближе к концу с высоким адресом и т. Д.

Ядро Linux использует аналогичную технику для сжатия имен символов, которые используются для печати следов стека вызовов подпрограммы. Смотрите файл scripts / kallsyms.c. Например, https://code.woboq.org/linux/linux/scripts/kallsyms.c.html

Руководство zlib рекомендует размещать наиболее распространенные вхождения в конце словаря.

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

Это потому, что LZ77 имеет алгоритм скользящего окна, поэтому более поздние подстроки будут доступны дальше в вашем потоке данных, чем первые несколько.

Я бы поиграл с генерацией словаря на языке более высокого уровня с хорошей поддержкой строк. Пример грубого JavaScript:

var str = "The dictionary should consist of strings (byte sequences) that"
    + " are likely to be encountered later in the data to be compressed,"
    + " with the most commonly used strings preferably put towards the "
    + "end of the dictionary. Using a dictionary is most useful when the"
    + " data to be compressed is short and can be predicted with good"
    + " accuracy; the data can then be compressed better than with the "
    + "default empty dictionary.";
// Extract words, remove punctuation (extra: replace(/\s/g, " "))
var words = str.replace(/[,\;.:\(\)]/g, "").split(" ").sort();
var  wcnt = [], w = "", cnt = 0; // pairs, current word, current word count
for (var i = 0, cnt = 0, w = ""; i < words.length; i++) {
    if (words[i] === w) {
        cnt++; // another match
    } else {
        if (w !== "")
            wcnt.push([cnt, w]); // Push a pair (count, word)
        cnt = 1; // Start counting for this word
        w = words[i]; // Start counting again
    }
}
if (w !== "")
    wcnt.push([cnt, w]); // Push last word
wcnt.sort(); // Greater matches at the end
for (var i in wcnt)
    wcnt[i] = wcnt[i][1]; // Just take the words
var dict = wcnt.join("").slice(-70); // Join the words, take last 70 chars

Тогда dict - это строка из 70 символов с:

rdsusedusefulwhencanismostofstringscompresseddatatowithdictionarybethe

Вы можете попробовать скопировать-вставить-запустить здесь (добавить: "print (dict)")

Это просто целые слова, а не подстроки. Также есть способы перекрытия общих подстрок для экономии места в словаре.

...