Zstd: 압축 컨텍스트가 주기적으로 폐기되는 경우 더 나은 압축 비율

안녕하세요 @scherepanov ,

이 결과는 놀랍습니다.
동일한 입력과 동일한 압축 수준으로 ZSTD_compressCCtx() 를 사용하면 컨텍스트가 재사용되는지 여부가 중요하지 않습니다 (압축 비율 관점에서). 컨텍스트 재사용의 유일한 영향은 할당 및 초기화 시간을 절약하는 것입니다. 압축률에 영향을 준다면 이상하고 아마 틀린 것일 수도 있습니다.

가능하다면이 시나리오를 재현하고 싶습니다. 어떤 버전을 사용하고 있습니까?

큰 데이터 청크를 압축하는 사이에 압축 컨텍스트를 버리는 것이 더 나은 방법입니까?

컨텍스트를 버릴 필요가 없습니다.
"좋은"유일한 이유는 코드를 단순화하는 것입니다.
그러나 성능 측면에서 볼 때 이점이 있어야하며 단점이 없어야합니다.

권장되는 최적의 입력 버퍼 크기는 무엇입니까?

이것은 매우 상황 적입니다. "보편적 인"임계 값은 없습니다.
일반적으로 8x 창 크기를 초과하면 청크 크기를 늘리는 것이 점점 덜 가치가 있습니다.
그러나 창 크기는 압축 수준에 따라 동적 값입니다.
512KB (레벨 1)에서 8MB (레벨 19)까지 다양합니다.

zstd에게 "원하는만큼의 메모리를 사용하지만 더 나은 압축률을 제공하십시오"라고 알리는 방법

레벨 19는 이런 종류 여야합니다

및 / 또는 속도 "

레벨 4는 일반적으로 이런 종류입니다. 압축 속도가 매우 빠르지 만 메모리를 많이 사용합니다. 그것은 내가 생각할 수있는 가장 가까운 것입니다.

메모리가 제한된 사용 사례에서만 컨텍스트가있는 스트리밍 압축입니까? 메모리가 많으면 큰 (> 1MB) 버퍼를 독립적으로 압축하는 것이 더 낫습니까?

단일 패스 ( ZSTD_compressCCtx() 및 ZSTD_decompressDCtx() )에서 독립적 인 청크를 압축 / 압축 해제하는 것이 더 간단하고 효율적일 수 있습니다. 할 수 있다면 더 좋습니다. 스트리밍 모드는 그 외에도 많은 복잡성을 추가합니다. 복잡성은 대부분 내부적이며 숨겨져 있지만 주요 아이디어는 간단한 원 패스 압축 또는 압축 해제보다 빠를 수 없다는 것입니다.

매우 명확한 답변에 감사드립니다.
내 데이터의 다른 순서에 따라 다른 압축 비율을 추적했습니다. 예, 컨텍스트를 재사용하는 것과 버리는 것은 당신이 말한 것과 똑같이 차이를 만들지 않습니다. 죄송합니다. 질문을 제출하기 전에 더 조심하고 더 자세히 조사해야합니다.
귀하의 의견은 매우 명확하고 설명이 잘되어 있습니다. 정말 문서에 추가해야한다고 생각합니다. 특히 스트리밍과 비 스트리밍의 차이점에 대한 부분-사전을 더 잘 구축 할 수 있기 때문에 스트리밍이 더 효율적이라고 항상 생각했습니다 (파일에서 데이터가 변경 될 때 사전을 수정하는 방법은 명확하지 않음). 스트리밍이 "블록 기반"압축과 거의 동일하다는 명확한 이해는 매우 중요합니다. 반면에 청크 크기를 자동으로 처리하므로 스트리밍이 더 효율적일 수 있습니다. 기본 압축 수준 3의 1MB 청크 크기를 사용하고 있으며 더 나은 압축을 얻기에는 충분하지 않은 것 같습니다. 이러한 관점에서 볼 때 청크 크기를 더 최적으로 결정할 수 있으므로 스트리밍이 압축 비율에서 더 효율적일 수 있습니다. (이 올바른지???)

스트리밍은 "블록 기반"압축과 거의 동일합니다.

정확히 "같은"것은 아닙니다.

입력 데이터를 청크로 잘라내어 ZSTD_compressCCtx() 독립적으로 전달하면 여러 개의 독립적 인 압축 청크가 생성됩니다. 압축 된 각 청크는 독립적 인 _frame_입니다. 각 프레임은 독립적이기 때문에 어떤 순서로든 압축을 풀 수 있습니다.

청킹없이 ZSTD_compressStream() 하여 동일한 데이터를 단일 스트림으로 전송하면 _single frame_이됩니다. 내부적으로는 프레임이 블록으로 절단되지만 블록은 독립적이지 않기 때문에 중요하지 않습니다. 프레임의 일부를 디코딩하려면 처음부터 모든 것을 디코딩해야합니다.

이론적으로 단일 프레임은 여러 개의 독립 프레임보다 더 잘 압축되어야합니다. 데이터를 여러 개의 독립적 인 청크로 자르면 각 청크의 시작 부분에서 압축 기회를 잃게되기 때문입니다.
그러나 빠른 모드는 단지 "확률 적"압축기로, 빠르게 실행하기 위해 서둘러 베팅을합니다. 모든 기회가 동일하지는 않으며 때로는 하나의 기회를 선택하면 나중에 더 나은 기회를 가릴 수 있습니다. 이것은 매우 데이터에 따라 다릅니다.
따라서 드물게 데이터를 독립적 인 청크로 절단하면 단일 스트림과 경쟁하게 될 수 있습니다.
그러나 나는 그것에 내기하지 않을 것입니다. 대부분의 경우 단일 스트림이 이길 것입니다.