Wed, 26 Nov 2014 23:21:20 -0800 obsstore: prefetch struct.calcsize
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 23:21:20 -0800] rev 23498
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.
Wed, 26 Nov 2014 16:58:31 -0800 obsstore: disable garbage collection during initialization (issue4456)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 16:58:31 -0800] rev 23497
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.
Thu, 04 Dec 2014 05:43:15 -0800 dirstate: use the 'nogc' decorator
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 05:43:15 -0800] rev 23496
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.
Thu, 04 Dec 2014 05:43:40 -0800 util: add a 'nogc' decorator to disable the garbage collection
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Dec 2014 05:43:40 -0800] rev 23495
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.
Fri, 05 Dec 2014 22:58:02 -0500 generate-working-copy-states: open() in binary mode when writing content
Matt Harbison <matt_harbison@yahoo.com> [Fri, 05 Dec 2014 22:58:02 -0500] rev 23494
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
Fri, 05 Dec 2014 16:45:52 -0800 largefiles: don't use 'r' action for standin that doesn't exist
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:45:52 -0800] rev 23493
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.
Fri, 05 Dec 2014 16:51:37 -0800 largefiles: don't use 'r' action for normal file that doesn't exist
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Dec 2014 16:51:37 -0800] rev 23492
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.
Tue, 02 Dec 2014 12:23:12 -0800 rebase: handle revtodo as a special value when storing/restoring state
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 02 Dec 2014 12:23:12 -0800] rev 23491
rebase: handle revtodo as a special value when storing/restoring state Revtodo happens to share its value with nullrev, but this is an implementation details, so we move away from it. After this changeset one can successfully change the values for all the constants and the tests still pass, but doing so would require more refactoring if we want to avoid breaking backward compatibility on the state file.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip