Wed, 22 Mar 2017 21:09:28 +0100 stablerange: remove the now unused individual range class
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.
Wed, 22 Mar 2017 21:08:58 +0100 stablerange: directly use tuple to refer to a stable range
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.
Wed, 22 Mar 2017 21:28:18 +0100 obshash: properly cache obshash value
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.
Wed, 22 Mar 2017 20:59:42 +0100 stablerange: directly use 'self' when possible
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.
Wed, 22 Mar 2017 20:56:17 +0100 revsfromrange: set the cache for the multiple bottom ranges in merge slicing
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.
Wed, 22 Mar 2017 20:55:43 +0100 revsfromrange: set the cache for the single bottom range in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:55:43 +0100] rev 2192
revsfromrange: set the cache for the single bottom range in merge slicing We no longer rely on the object magic here.
Wed, 22 Mar 2017 20:55:23 +0100 revsfromrange: set the cache for the top range in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:55:23 +0100] rev 2191
revsfromrange: set the cache for the top range in merge slicing We no longer rely on the object magic here.
Wed, 22 Mar 2017 20:44:29 +0100 revsfromrange: remove reference to '_revs' in merge slicing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:44:29 +0100] rev 2190
revsfromrange: remove reference to '_revs' in merge slicing Given '_revs' is a property from the cache, we use the official method of the object we are on instead. That method should be using the same cache than the property if available.
Wed, 22 Mar 2017 20:37:27 +0100 revsfromcache: update cache for the top slice if possible
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:37:27 +0100] rev 2189
revsfromcache: update cache for the top slice if possible Same logic, we update the cache if have the data.
Wed, 22 Mar 2017 20:37:03 +0100 revsfromrange: skip setting the cache for length-1 top entry
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:37:03 +0100] rev 2188
revsfromrange: skip setting the cache for length-1 top entry The content of the range is trivial to compute.
Wed, 22 Mar 2017 20:36:19 +0100 revsfromrange: update cache for parentrange directly in the code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:36:19 +0100] rev 2187
revsfromrange: update cache for parentrange directly in the code We update it where it matters if we detect that we have the data.
Wed, 22 Mar 2017 20:34:07 +0100 revsfromramge: hard code the single changeset range case
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:34:07 +0100] rev 2186
revsfromramge: hard code the single changeset range case That case is trivial and triggering and full stable sort for it seems a bit silly.
Wed, 22 Mar 2017 20:18:01 +0100 stablerange: introduce caching for the full revision in a set
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:18:01 +0100] rev 2185
stablerange: introduce caching for the full revision in a set Such cache proved handy in the "per-range" class so we carry it along to the unified class. cf documentation for details.
Wed, 22 Mar 2017 20:11:19 +0100 stablerange: add a cache for stablesort ordering
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:11:19 +0100] rev 2184
stablerange: add a cache for stablesort ordering This will be very handy for merge, cf inline documentation for details.
Wed, 22 Mar 2017 20:05:21 +0100 stablerange: move revs computation within the main class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 20:05:21 +0100] rev 2183
stablerange: move revs computation within the main class We still need to compute the revision withing a range when we slice a merge. This is the last large logic that remains in the individual class and we migrate is on the main class.
Wed, 22 Mar 2017 19:42:37 +0100 stablerange: minor method reorders on the main class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 22 Mar 2017 19:42:37 +0100] rev 2182
stablerange: minor method reorders on the main class We put the public method first for clarify.
(0) -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 tip