В настоящее время я пытаюсь использовать zlib для сжатия в одном из моих проектов. Я взглянул на базовый учебник zlib , и меня смущают следующие утверждения:
CHUNK - это просто размер буфера для подачи и извлечения данных.
из подпрограмм zlib. Больший размер буфера будет более эффективным,
особенно для инфляции (). Если память доступна, размеры буфера на
следует использовать порядок байтов 128 КБ или 256 КБ.
# определить CHUNK 16384
В моем случае у меня всегда будет небольшой буфер, уже доступный на выходном конце (около 80 байт), и я буду постоянно передавать очень маленькие данные (несколько байтов) со стороны ввода через zlib. Это означает, что у меня не будет большего буфера с обеих сторон, но я планирую использовать гораздо меньшие.
Однако я не уверен, как интерпретировать «больший размер буфера будет более эффективным». Относится ли это к эффективности кодирования или эффективности времени / пространства?
Одна идея, которую я должен исправить в этой ситуации, состоит в том, чтобы добавить еще несколько слоев буферизации, накопленных на входе, и многократно сбрасывать на выход. Однако это означало бы, что мне придется накапливать данные и добавлять к своим данным еще несколько уровней копирования, что также снизит производительность.
Теперь, если эффективность - это просто эффективность времени / пространства, я мог бы просто измерить влияние обоих методов и выбрать один из них. Однако, если на фактическое кодирование может влиять меньший размер буфера, это может быть действительно трудно обнаружить.
У кого-нибудь есть опыт использования zlib с очень маленькими буферами?