Gregory Szorc <gregory.szorc@gmail.com> [Sun, 20 Dec 2015 19:02:02 -0800] rev 27469
commands: use revlog._deltachain in debugdeltachain
We have a nice API now. Use it.
This does mean we introduce an extra index lookup for each revision.
Considering this is a debug command, the overhead should be acceptable.
We could add the chain size to revlog._deltachain(). However, that
feels like avoidable overhead.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 20 Dec 2015 18:56:05 -0800] rev 27468
revlog: refactor delta chain computation into own function
This code is already written in multiple locations.
While this code needs to be fast and extracting it to its own function
adds overhead, code paths reading delta chains typically read,
decompress, and do binary patching on revlog data from the delta chain.
This other work (especially zlib decompression) almost certainly
accounts for a lot more time than the overhead of introducing a Python
function call. So I'm not worried about the performance impact of this
change.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 20 Dec 2015 17:57:44 -0800] rev 27467
perf: call clearcaches() in perfmanifest
The old code only partially cleared the caches. Now that we have a
comprehensive method for wiping all caches, let's call it.
This appears to introduce a marginal regression in `hg perfmanifest`
on mozilla-central. This is good because the new result is more
accurate since caches aren't being used.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 20 Dec 2015 19:31:46 -0800] rev 27466
manifest: implement clearcaches()
The manifest implements its own caches in addition to revlog's. Extend
the base clearcaches() to wipe these as well.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 20 Dec 2015 17:48:20 -0800] rev 27465
revlog: make clearcaches() more effective
clearcaches() was added several years ago in e8d37b78acfb as part
of implementing a perf command. Since revlog instances have many caches
and since the spirit of this mostly unused method is to facilitate
performance testing, I think it's appropriate for all the revlog's
caches to get cleared when it is called.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 21 Dec 2015 22:31:16 +0900] rev 27464
fileset: detect unintentional existing() invocation at runtime
A fileset predicate can invoke 'matchctx.existing()' successfully,
even if it isn't marked as "existing caller". It is aborted only in
some corner cases: e.g. there were one deleted file in the working
directory (see 8a0513bf030a for detail).
This patch makes 'matchctx.existing()' invocation abort if not
'_existingenabled', which is true only while "existing caller"
running.
After this changes, non-"existing caller" predicate function is
aborted immediately, whenever it invokes 'matchctx.existing()'. This
prevent developer from forgetting to mark a predicate as "existing
caller".
BTW, unintentional 'matchctx.status()' invocation can be detected
easily without any additional trick like this patch, because it
returns 'None' if a predicate isn't marked as "status caller", and
referring field (e.g. '.modified') of it is always aborted.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 21 Dec 2015 22:31:16 +0900] rev 27463
fileset: use set instead of list to mark predicates for efficiency (API)
This reduces cost of examining whether given predicate calls
'matchctx.status()' or 'matchctx.existing()' in 'getfileset()' at
runtime.
This kind of examination is used also in subsequent patch, which
detects unintentional 'matchctx.existing()' invocation per each
predicate evaluation.