obsstore: cache size computation for fm1 node
We have two different types of node type (sha1 and sha256, only sha1 is used
now) and therefor different sizes for them. We now compute the value once
instead of redoing the computation every loop. This has no visible performance
impact.
obsstore: prefetch struct.calcsize
This function is widely used and worth but be at module level. No specific
performance boost is visible, but this is more consistent.
obsstore: disable garbage collection during initialization (
issue4456)
Python garbage collection is triggered by container creation. So code that
creates a lot of tuples tends to trigger GC a lot. We disable the gc during
obsolescence marker parsing and associated initialization. This provides an
interesting speedup (25%).
Load marker function on my 58758 markers repo:
before: 0.468247 seconds
after: 0.344362 seconds
The benefit is a bit less visible overall. With python2.6 on my system I see:
after: 0.60
before: 0.53
The difference is probably explained by the delaying of a costly GC. (but there
is still a win). Marking involved tuples, lists and dicts as ignorable by the
garbage collector should give us more benefit. But this is another adventure.
Thanks goes to Siddharth Agarwal for the lead.
dirstate: use the 'nogc' decorator
Now that we have a generic way to disable the gc, we use it. however, we have too
use it in a baroque way. See inline comment for details.
util: add a 'nogc' decorator to disable the garbage collection
Garbage collection behave pathologically when creating a lot of containers. As
we do that more than once it become sensible to have a decorator for it. See
inline documentation for details.
generate-working-copy-states: open() in binary mode when writing content
This avoids changes to the hashes on Windows in test-merge-force.t like so:
@@ -594,12 +594,12 @@
content2
M missing_content2_content3_content4-tracked
- <<<<<<< local:
443153eb5b88 - test: local\r (esc)
- content4
- ||||||| base
- =======
- content2
- >>>>>>> other:
9b2ccd328a08 - test: remote\r (esc)
+ <<<<<<< local:
0447570f1af6 - test: local
+ content4
+ ||||||| base
+ =======
+ content2
+ >>>>>>> other:
85100b8c675b - test: remote
missing_content2_content3_content4-tracked.orig:
content4
largefiles: don't use 'r' action for standin that doesn't exist
When merging and the remote has turned a normal file into a largefile
and the user chooses to keep the local largefile, we use the 'r'
action for the remote largefile standin. This is wrong, since that
file does not exist in the parent of the working copy. Use 'k', which
does nothing but debug logging, instead.
largefiles: don't use 'r' action for normal file that doesn't exist
When merging and the remote has turned a largefile into a normal file
and the user chooses to keep the local largefile, we use the 'r'
action for the remote normal file. This is wrong, since that file does
not exist in the parent of the working copy. Use 'k', which does
nothing but debug logging, instead.