Mercurial > hg
changeset 21810:4b2ebd3187a1
dirstate.status: assign members one by one instead of unpacking the tuple
With this patch, hg status and hg diff regain their previous speed.
The following tests are run against a working copy with over 270,000 files.
Here, 'before' means without this or the previous patch applied.
Note that in this case `hg perfstatus` isn't representative since it doesn't
take dirstate parsing time into account.
$ time hg status # best of 5
before: 2.03s user 1.25s system 99% cpu 3.290 total
after: 2.01s user 1.25s system 99% cpu 3.261 total
$ time hg diff # best of 5
before: 1.32s user 0.78s system 99% cpu 2.105 total
after: 1.27s user 0.79s system 99% cpu 2.066 total
author | Siddharth Agarwal <sid0@fb.com> |
---|---|
date | Tue, 27 May 2014 21:02:16 -0700 |
parents | e250b8300e6e |
children | 789b69d597cc |
files | mercurial/dirstate.py |
diffstat | 1 files changed, 12 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/mercurial/dirstate.py Tue May 27 14:27:41 2014 -0700 +++ b/mercurial/dirstate.py Tue May 27 21:02:16 2014 -0700 @@ -823,7 +823,18 @@ uadd(fn) continue - state, mode, size, time = dmap[fn] + # This is equivalent to 'state, mode, size, time = dmap[fn]' but not + # written like that for performance reasons. dmap[fn] is not a + # Python tuple in compiled builds. The CPython UNPACK_SEQUENCE + # opcode has fast paths when the value to be unpacked is a tuple or + # a list, but falls back to creating a full-fledged iterator in + # general. That is much slower than simply accessing and storing the + # tuple members one by one. + t = dmap[fn] + state = t[0] + mode = t[1] + size = t[2] + time = t[3] if not st and state in "nma": dadd(fn)