Zstd: ZSTD_c_targetCBlockSize == ZSTD_TARGETCBLOCKSIZE_MAX conduce a una compresión improbablemente mala

Creado en 28 abr. 2020  ·  3Comentarios  ·  Fuente: facebook/zstd

El uso de ZSTD_CCtxParams_setParameter(cctxParams, ZSTD_c_targetCBlockSize, ZSTD_TARGETCBLOCKSIZE_MAX) conduce a una compresión improbablemente mala para fuentes con secuencias mínimas grandes (> 1kB).

Usando una concatenación repetida de un CSS minificado:
Con la configuración targetCBlockSize == ZSTD_TARGETBLOCKSIZE_MAX:
bootstrap.min.css : 97.31% (13862462 => 13488900 bytes, bootstrap.min.css.zst)
Sin configurar targetCBlockSize:
bootstrap.min.css : 0.15% (13862462 => 20476 bytes, bootstrap.min.css.zst)

Nota adicional: encontré esto como resultado de intentar reducir el tamaño del bloque al descomprimir con respecto a # 2093. Si en lugar de establecer TargetCompressedBlockSize, el propio ZSTD_BLOCKSIZEMAX se reduce, lo que a su vez hace que también se reduzca el tamaño máximo de bloque, tiene un impacto mucho menor en la compresión.


La fuente utilizada se obtuvo mediante la siguiente secuencia:
rm bootstrap.min.css; wget https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css && for i in {1..5}; do cat bootstrap.min.css >> bootstrap_2.min.css; cat bootstrap_2.min.css >> bootstrap.min.css; done && rm bootstrap_2.min.css

bug release-blocking

Comentario más útil

@dciliske He reproducido el problema en el nivel 22. No está presente en zstd-1.4.4, por lo que nunca llegó a ser una versión. Parece que lo presenté en

Todos 3 comentarios

Voy a hacer una pregunta aquí con respecto a la arquitectura: ¿targetCBlockSize hace que el compresor asuma que se va a alimentar a un descompresor que no tendrá conocimiento fuera del bloque que recibe? es decir, ¿es un descompresor de transmisión sin búfer?

targetCBlockSize está "destinado" a ser utilizado en escenarios de transmisión en los que desea reducir el tiempo para descomprimir el primer byte. Entonces, si el tamaño de su paquete es de 4 KB, puede establecer el tamaño de bloque de destino en 4 KB e intentar hacer que cada paquete sea descomprimible, en lugar de tener que esperar hasta 128 KB completos antes de descomprimir el primer byte.

No estoy seguro de qué está sucediendo en este escenario, pero con la entrada debería ser fácil de reproducir y corregir. Lo investigaré pronto. Gracias de nuevo por el informe y las instrucciones detalladas de reproducción.

@dciliske He reproducido el problema en el nivel 22. No está presente en zstd-1.4.4, por lo que nunca llegó a ser una versión. Parece que lo presenté en

¿Fue útil esta página
0 / 5 - 0 calificaciones