- Mar 27, 2024
-
-
Pierre-Yves David authored
This looks like a good place for it to live.
-
Pierre-Yves David authored
This otherwise defeat some of the branch v3 optimization.
-
- Mar 26, 2024
-
-
Pierre-Yves David authored
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 authored
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 authored
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 authored
In some case, the context manager version will be simpler.
-
Pierre-Yves David authored
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 authored
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 authored
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 authored
That generator simply return chunks so we should not assign the return to a tuple.
-
Pierre-Yves David authored
We were fetching a v1 generator but actually using the v2 function…
-
- Mar 29, 2024
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Mar 28, 2024
-
-
Pierre-Yves David authored
This bundle2 part is about helping the client to warms its cache. There is no reason for it to be mandatory. So we mark it advisory.
- Mar 25, 2024
-
-
Pierre-Yves David authored
-
- Mar 07, 2024
-
-
Pierre-Yves David authored
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 authored
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.
-
- Mar 06, 2024
-
-
Pierre-Yves David authored
In a future changeset, this will allow the V3 of the branch cache to use a fast path when possible.
-
Pierre-Yves David authored
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 authored
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 authored
Since we won't do anything with the obsolete revisions, we can just ignore them sooner.
-
- Mar 07, 2024
-
-
Pierre-Yves David authored
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 authored
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.
-
- Mar 06, 2024
-
-
Pierre-Yves David authored
This will avoid the bug covered in tests/test-branches-obsolete.t when we stop storing all heads explicitly in V3.
-
Pierre-Yves David authored
This help to track the changes in format between v2 and v3.
-
Pierre-Yves David authored
We now have a more flexible `key_hashes` tuple. We duplicated various logic in the V2 and V3 version of the cache as the goal is to start changing the logic for V3 in the next few changesets.
-
Pierre-Yves David authored
The new name is less ambiguous, as we are about to introduce an alternative function it seems like a good idea to have clearer name to distinct the two.
-
Pierre-Yves David authored
The branch2's filteredhash combines the filtered revisions and the obsolete ones, this will creates issue for implicit reference to heads we want to introduce for the v3 of the branch cache format. So we isolate this logic for alternative use.
-
- Mar 05, 2024
-
-
Pierre-Yves David authored
This will help us to reuse this logic in variants of the hashes used for branch cache validation.
-
- Feb 25, 2024
-
-
Pierre-Yves David authored
A lot of duplicated work seemed to be done, as we already update the tiprev and tipnode when needed right before. So we simplify that part to focus on the filtered hash. See inline comment for details.
-
- Feb 28, 2024
-
-
Pierre-Yves David authored
While working on branch-cache-v3, we noticed some ambiguity in the filtered+obsolete hash. However this was only caught by a rebase test by chance. It seems important to explicitly tests these cases.
-
- Feb 26, 2024
-
-
Pierre-Yves David authored
The key-value approach is clearer and gives more rooms to have the format evolve in a clear way. It also provides extension (like topic) simpler way to extend the validation scheme. This is just a small evolution, the V3 format is still a work in progress.
-
Pierre-Yves David authored
For now the format is the very same, however we will start changing it in future changesets.
-
- Feb 27, 2024
-
-
Pierre-Yves David authored
This prepare the introduction of an experimental v3 format version. In the process, we move the description of the format in that new class.
-
Pierre-Yves David authored
This helps each section to stand out.
-
- Mar 25, 2024
-
-
Pierre-Yves David authored
Apparently iterating over the `changed_revs` dictionary is very expensive. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds prev-changeset: 30.0 seconds this-changeset: 4.6 seconds So, the performance regression is gone. Once again: thanks to marvelous Python!
-
Pierre-Yves David authored
If we retract for the draft phase, there is not non-public item to be retracted and we can skip this part. This part is was apparently super costly thanks to Python. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds this-changeset: 30.0 seconds So we recovered about ⅔ of the regression, the next changeset will give us the rest back.
-
- Mar 21, 2024
-
-
Raphaël Gomès authored
-