Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 11:04:38 +0100] rev 2222
stablerange: fix merge slicing when range has multiple roots
The first element in the bottom set is not necessarly the one with the lowest
revision. We now properly compute and use the minimum value.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 09:04:34 +0100] rev 2221
stablerange: small style fix
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:16:00 +0100] rev 2220
merge-slicing: introduce and use "inheritance point" for merge
The first part of the stable sorted list of revision of a merge will shared with
the one of others. This means we can reuse subranges computed from that point to
compute some of the subranges from the merge.
That point is latest point in the stable sorted list where the depth of the
revisions match its index (that means all revision earlier in the stable sorted
list are its ancestors, no dangling unrelated branches exists). This is a bit
expensive to find since we have to walk all the revision, but being able to
reuse subranges in all case (not just regular changesets) provide a massive
speedup so the cost is worth it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:31:10 +0100] rev 2219
stablerange: rearrange the code picking subrange to warm
Same logic, as the previous changesets, we prepare the code before adding merge
support.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 08:20:36 +0100] rev 2218
stablerange: rearrange the reusing logic to prepare to merge
We'll soon be able to reuse some lower range when dealing with merge too. So we
prepare the code for this in advance for clarity.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:24:02 +0100] rev 2217
merge-slicing: explain an alternative implementation in a comments
It has a better time complexity so a C implementation would likely out perform
the current implementation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:36:12 +0100] rev 2216
merge-slicing: use reachable roots to filter the various branches
Reachable roots does what we want and have a quite fast C implementation.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:51:20 +0100] rev 2215
merge-slicing: simplify various aspect of the code
Especially the case were the bottom have single heads is not more efficiently
handled.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 14:17:15 +0100] rev 2214
stablerange: soon it will not provide any benefit and it gets in the way
This was a bit strange and memory consuming anyway.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 06:31:32 +0100] rev 2213
revsfromrange: reuse information from the stablesort
We collaborate with the stablesort to store the order that led to a merge. That
way, when we needs to retrieve revision from that merge we can reuse that order.
We might need to filter to only retains ancestors of the merge we care about but
skipping the stablesort safe a large amount of time.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:22:56 +0100] rev 2212
stablesort: allow a callback to be triggered on merge
Storing some information as we sort is going to be useful to avoid performing
multiple sort while computing the stablerange.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:33:36 +0100] rev 2211
minor simplification around rangelength
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 03:30:14 +0100] rev 2210
more explicite name in revsfromrange
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 24 Mar 2017 05:15:25 +0100] rev 2209
stablerange: cache parents
We happens to be doing and awful amount of parent call. We cache them locally
for efficiency.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 12:53:39 +0100] rev 2208
merge-slicing: avoid doing the same work twice
We have already computed the list of revision in that bottom slice as 'hrevs' so
we do not need to compute it a second time.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 14:16:43 +0100] rev 2207
stablerange: fix a bug when a top slice ended on a merge
Our "smart" detection of merge was buggy if the top slice ended on a merge. This
is not fixed and tested.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:49:03 +0100] rev 2206
slicesrangeat: stop double setting the revsinranges cache
The cache should have already been filled by the logic warming the cache for the
parent.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:44:12 +0100] rev 2205
subranges: remove the recursivity of the call to isubranges(parentrange)
We add some logic to ensure we'll have hot cache for the parent ranges when that
matters, the cache is filled from ancestors to descendant to ensure this. The
range are still 'created from descendant to ancestors to fill the revsfromrange
cache since it important.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:19:59 +0100] rev 2204
subranges: detach cache logic from computation logic
Having both the logic around cache checking and setting makes is a bit harder to
follow. In addition, this allow to gather the computation logic next to the
other related function.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:07:21 +0100] rev 2203
findmissingrange: properly queue new subrange for slicing
The previous code was buggy and used the wrong variable leading to no extra
slicing being performed to file the sample at the requested size.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 10:06:20 +0100] rev 2202
findmissingrange: fix reversed value in debug output
"oops"
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 22:05:30 +0100] rev 2201
stablecache: warmup on unfiltered repository
We only looks at ancestors revision so filtering will not have any effect. This
reduce overhead from the filtering.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:11:35 +0100] rev 2200
stablerange: rename the class
This is much more than just a cache now.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 23 Mar 2017 09:40:04 +0100] rev 2199
stablerange: do not inherit from dict
This seems like and old cargo cult that when unnoticed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:10:01 +0100] rev 2198
stablerange: move a utility function around
It make more sense to have this small function earlier in the series
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:09:28 +0100] rev 2197
stablerange: remove the now unused individual range class
That class is now longer necessary, we dropped its usage for performance reason.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:08:58 +0100] rev 2196
stablerange: directly use tuple to refer to a stable range
Now that all advance logic lives in the unified class we no longer needs the
individual class. Creating and operating on this cache introduce a significant
overhead that we can not stop having.
From now on, a range a is pair tuple '(headrev, index)'. Long live the tuple.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 21:28:18 +0100] rev 2195
obshash: properly cache obshash value
The code was buggy and only cached non-nullid/non-inherited value. This was
previous hidden because we were using a 'propertycache' to cache the value on
the range object. This fixes it and restore a lot of performance.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:59:42 +0100] rev 2194
stablerange: directly use 'self' when possible
Code movement introduced multiple silly case were we where accessing 'self'
though 'repo.stablerange' for no good reasons.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:56:17 +0100] rev 2193
revsfromrange: set the cache for the multiple bottom ranges in merge slicing
We no longer rely on the object magic here.