Page MenuHomePhabricator

bundle: add option to avoid checking further delta candidates [POC]
Needs RevisionPublic

Authored by joerg.sonnenberger on Dec 19 2020, 9:44 AM.

Details

Reviewers
indygreg
baymax
Group Reviewers
hg-reviewers
Summary

Especially when applying a clone bundle and the follow-up pull, the
deltas will be nearly optimal. Add a test config flag to skip any
attempts at finding a better delta base. Test base for how this
interacts with parallel delta compression in addgroup.

Test with a bundle of the HG repo: -2%, non-noticable size difference
Test with a bundle of the NetBSD src repo: -18%, +10% manifest size

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

Some further tests show that this is indeed primarily the manifest handling. There are some peculiarities with the commit graph of this specific repository, so this likely doesn't apply to other repositories as much.

I feel like effrot would be better spend generating better bundle (or adding more delta related information in the bundle) than doing this kind of changes.

It was primarily meant to identify problem areas. The primary win here is skipping the delta finding for manifests. It seems like the problem is that we force a delta to be generated for snapshots and the target repo doesn't completely agree on when snapshots are supposed to happen. Given the size of the manifests here, the delta generation is reasonable expensive.

It was primarily meant to identify problem areas. The primary win here is skipping the delta finding for manifests. It seems like the problem is that we force a delta to be generated for snapshots and the target repo doesn't completely agree on when snapshots are supposed to happen. Given the size of the manifests here, the delta generation is reasonable expensive.

Do you have timing about the amount of time we spend in snapshot/semi-snapshot vs the rest of the unbundle ?

baymax requested changes to this revision.May 25 2021, 5:32 AM

There seems to have been no activities on this Diff for the past 3 Months.

By policy, we are automatically moving it out of the need-review state.

Please, move it back to need-review without hesitation if this diff should still be discussed.

:baymax:need-review-idle:

This revision now requires changes to proceed.May 25 2021, 5:32 AM