Wed, 17 Jan 2024 14:26:58 +0100 vfs: have tryunlink tell what it did
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:26:58 +0100] rev 51430
vfs: have tryunlink tell what it did It is useful in certain circumstances to know whether vfs.tryunlink() actually removed something or not, be it for logging purposes.
Sat, 26 Nov 2022 12:23:56 +0100 chainsaw: new extension for dangerous operations
Georges Racinet <georges.racinet@octobus.net> [Sat, 26 Nov 2022 12:23:56 +0100] rev 51429
chainsaw: new extension for dangerous operations The first provided command is `chainsaw-update`, whose one and single job is to make sure that it will pull, update and purge the target repository, no matter what may be in the way (locks, notably), see docstring for rationale.
Fri, 23 Feb 2024 03:45:07 +0100 rust: disable the RustIndex without persistent nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:45:07 +0100] rev 51428
rust: disable the RustIndex without persistent nodemap See rational inline.
Fri, 23 Feb 2024 03:44:56 +0100 rust: stop claiming the C index is compatible with the rust code
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:44:56 +0100] rev 51427
rust: stop claiming the C index is compatible with the rust code This is no longer the case since the introduction of the pure Rust Index, and was probably not the case since the MixedIndex itself. So we fix the dedicated attribute value.
Thu, 22 Feb 2024 15:11:26 +0100 rust-index: remove one collect when converting back
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:11:26 +0100] rev 51426
rust-index: remove one collect when converting back Turns out this is slightly faster. Sending the results back to Python is still the most costly (like 75% of the time) of the whole method, but it's about as fast as it can be now. hg perf::phases on mozilla-try-2023-03-22 before: 0.267114 after: 0.247101
Thu, 22 Feb 2024 15:06:16 +0100 rust-index: improve phase computation speed
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:06:16 +0100] rev 51425
rust-index: improve phase computation speed While less memory efficient, using an array is *much* faster than using a HashMap, especially with the default hasher. It even makes the code simpler, so I'm not really sure what I was thinking in the first place, maybe it's more obvious now. This fix a significant performance regression when using the rust version of the code. (however, the C code still outperform rust on this operation) hg perf::phases on mozilla-try-2023-03-22 - 6.6.3: 0.451239 seconds - before: 0.982495 seconds - after: 0.265347 seconds - C code: 0.183241 second
Fri, 23 Feb 2024 06:37:25 +0100 phases: directly update the phase sets in advanceboundary
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:37:25 +0100] rev 51424
phases: directly update the phase sets in advanceboundary This is similar to what we do in retractboundary. There is no need to invalidate the cache if we have everything at hand to update it.
Fri, 23 Feb 2024 05:25:35 +0100 phases: large rework of advance boundary
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 05:25:35 +0100] rev 51423
phases: large rework of advance boundary In a similar spirit as the rework of retractboundary, the new algorithm is doing an amount of work in the order of magnitude of the amount of changeset that changes phases. (except to find new roots in impacted higher phases if any may exists). This result in a very significant speedup for repository with many old draft like mozilla try. runtime of perf:unbundle for a bundle constaining a single changeset (C code): before 6.7 phase work: 14.497 seconds before this change: 6.311 seconds (-55%) with this change: 2.240 seconds (-85%) Combined with the other patches that fixes the phases computation in the Rust index, the rust code with a persistent nodemap get back to quite interresting performances with 2.026 seconds for the same operation, about 10% faster than the C code.
Thu, 22 Feb 2024 19:21:14 +0100 phases: apply similar early filtering to advanceboundary
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 19:21:14 +0100] rev 51422
phases: apply similar early filtering to advanceboundary advanceboundary is called the push's unbundle (but not the other unbundle) so advanceboundary did not show up the profile I looked at so far. We start with simple pre-filtering to avoid doing any work if we don't needs too.
Wed, 21 Feb 2024 11:09:25 +0100 phases: filter revision that are already in the right phase
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 11:09:25 +0100] rev 51421
phases: filter revision that are already in the right phase No need to compute new roots if everything is already in order.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip