Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:46:23 +0000] rev 51593
unbundle: move most of the logic on cmdutil to help debug::unbundle reuse
This make sure `hg debug::unbundle` focus on the core logic.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:29:48 +0000] rev 51592
postincoming: move to cmdutil
This looks like a good place for it to live.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:21:46 +0000] rev 51591
postincoming: avoid computing branchhead if no report will be posted
This otherwise defeat some of the branch v3 optimization.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:46:44 +0000] rev 51590
streamclone: stop listing files for entries that have no volatile files
This will save a lot of python related time.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
prev-change: 20.88 seconds (-40%)
prev-change: 14.22 seconds (-60%)
this-change: 11.58 seconds (-67% from baseline; -18% from prev)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:34:05 +0000] rev 51589
stream-clone: disable gc for the initial section for the v3 format
The number of small container created turn Python in a gc-frenzy that seriously
impact performance.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
prev-change: 20.88 seconds (-40%)
this-change: 14.22 seconds (-60% from baseline; -31% from prev)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:32:46 +0000] rev 51588
stream-clone: disable gc for `_entries_walk` duration
The number of small container created turn Python in a gc-frenzy that seriously
impact performance.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
this-change: 20.88 seconds (-40% from baseline; -15% from previous changes)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:28:52 +0000] rev 51587
nocg: make the utility work are both a decorator and context manager
In some case, the context manager version will be simpler.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 11:24:20 +0000] rev 51586
stream-clone: stop getting the file size of all file in v3
The point of v3 is to do less work in the locked section. It was currently not
the case.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.03 seconds
this-change: 24.50 seconds (-30%)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 18:55:40 +0000] rev 51585
stream: in v3, skip the "size" fast path if the entries as some unknown size
We are about to prefetch size during the lock less in the v3 case. So we need to
avoid trying to use that prefetched size when it is not available.
See next changeset for the motivation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:43:20 +0000] rev 51584
perf-stream-locked-section: advertise the right version key in the help
As the v3 format is still experimental, its key is "v3-exp". The help text was
not pointing that out.
(we also fix `perf::stream-generate` in the process)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:39:08 +0000] rev 51583
perf-stream-locked-section: fix the call to the v3 generator
That generator simply return chunks so we should not assign the return to a
tuple.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:36:47 +0000] rev 51582
perf-stream-locked-section: actually use v1 generation when requested
We were fetching a v1 generator but actually using the v2 function…
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Mar 2024 21:39:00 +0100] rev 51581
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 16:27:48 +0000] rev 51580
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 10:57:16 +0100] rev 51579
branchcache: allow to detect "pure topological case" for branchmap
We don't rum this detection every time we run the branchcache, that would be
costly. However we now do it when running `hg debugupdatecache`.
This will help existing repository to benefit from the fastpath when possible.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 04:15:23 +0100] rev 51578
branchcache: add a "pure topological head" fast path
In a narrow but actually quick common case, all topological heads are all on
the same branch and all open. In this case, computing the branch map is very
simple. We can quickly detect situation where this situation will not change.
So we update the V3 format to be able to express this situation and upgrade the
update code to detect we remains in that mode.
The branch cache is populated with the actual value when the branch map is
accessed, but the update_disk method can do the update without needing to
populate it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:18:03 +0100] rev 51577
branchcache: move the processing of the new data in a dedicated method
In a future changeset, this will allow the V3 of the branch cache to use a fast
path when possible.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:10:44 +0100] rev 51576
branchcache: gather newly closed head in a dedicated set
This is part of a series to more clearly split the update in two step. This
will allow us to introduce a fast path during update in a future changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:09:42 +0100] rev 51575
branchcache: gather new obsolete revision in a set
This is part of a series to more clearly split the update in two step. This
will allow us to introduce a fast path during update in a future changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 15:54:22 +0100] rev 51574
branchcache: filter obsolete revisions sooner
Since we won't do anything with the obsolete revisions, we can just ignore them
sooner.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 10:55:22 +0100] rev 51573
branchcache: skip entries that are topological heads in the on disk file
In the majority of cases, topological heads are also branch heads. We have
efficient way to get the topological heads and efficient way to retrieve
their branch information. So there is little value in putting them in the branch
cache file explicitly. On the contrary, writing them explicitly tend to create
very large cache file that are inefficient to read and update.
So the branch cache v3 format is no longer including them. This changeset focus
on the format aspect and have no focus on the performance aspect. We will cover
that later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 01:35:43 +0100] rev 51572
branchcache: simplify the branch rev cache test
We don't need that many content dump and this gets in the way in change in
access pattern (e.g. accessing revision in a different order change the order of
branches in the "names" file).
So we simplify this test in advance.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 11:39:44 +0100] rev 51571
branchcache: store filtered hash and obsolete hash independently for V3
This will avoid the bug covered in tests/test-branches-obsolete.t when we stop
storing all heads explicitly in V3.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 12:07:31 +0100] rev 51570
branchcache: show the cache file content in test-branches-obsoletes.t
This help to track the changes in format between v2 and v3.