Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix speed of --patch-from mode at high compression levels #4276

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

Cyan4973
Copy link
Contributor

@Cyan4973 Cyan4973 commented Jan 30, 2025

When employing --patch-from in combination with very high compression levels,
compression speed plummets significantly, becoming extremely slow.

This issue is mitigated by this patch,
which sensibly reduces compression time for this scenario.

Benchmark: patching linux-6.7.tar (~1.4GB) from linux-6.6.tar
on a M1 Pro laptop (employing 2 threads by default)

level dev this PR
18 250 s 80 s
19 350 s 118 s
20 420 s 145 s
21 510 s 200 s
22 635 s 320 s

The impact is even more pronounced with a larger amount of threads.
Benchmark on a core i7-9700k with 6 threads :

level dev this PR
18 208 s 34 s
19 264 s 48 s
20 300 s 63 s
21 352 s 88 s
22 472 s 160 s

Also: improved memory usage of --patch-from, by skipping an internal CDict creation that was duplicating reference content in memory.

@Cyan4973 Cyan4973 changed the title fix speed of --patch-from at high compression mode fix speed of --patch-from mode at high compression levels Jan 30, 2025
@Cyan4973 Cyan4973 self-assigned this Jan 31, 2025
@Cyan4973 Cyan4973 force-pushed the fix_patchfrom_hc_speed branch 2 times, most recently from c92d015 to e2aac8f Compare February 1, 2025 01:40
by avoiding to duplicate in memory
a dictionary that was passed by reference.
@Cyan4973 Cyan4973 marked this pull request as ready for review February 1, 2025 02:28
thus saving a bit of memory and a little bit of cpu time
--patch-from no longer blocked on first job dictionary loading
} else {
/* note : a loadPrefix becomes an internal CDict */
mtctx->cdictLocal = ZSTD_createCDict_advanced(dict, dictSize,
dictLoadMethod, dictContentType,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't actually care about the dictLoadMethod here, right? If it was ZSTD_dlm_byCopy, the outer ZSTD_CCtx must have already token ownership of the buffer. So we can use byRef here.

Suggested change
dictLoadMethod, dictContentType,
ZSTD_dlm_byRef, dictContentType,

@@ -1232,7 +1248,7 @@ static size_t ZSTDMT_computeOverlapSize(const ZSTD_CCtx_params* params)

size_t ZSTDMT_initCStream_internal(
ZSTDMT_CCtx* mtctx,
const void* dict, size_t dictSize, ZSTD_dictContentType_e dictContentType,
const void* dict, size_t dictSize, ZSTD_dictContentType_e dictContentType, ZSTD_dictLoadMethod_e dictLoadMethod,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we can always use byRef, we don't need to ass a dictLoadMethod in here.

const void* dict;
size_t dictSize;
ZSTD_dictContentType_e dictContentType;
} ZSTD_prefixDict;
ZSTD_dictLoadMethod_e loadMethod;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we can always use byRef in ZSTDMT, we don't need to store it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants