[MERGE][#230567] Faster (local) branch
ian.clatworthy at internode.on.net
Fri May 30 09:36:54 BST 2008
Aaron Bentley wrote:
> Stop it, Ian. Don't get stuck on your first idea. If there really are
> enhancements we can't achieve with a single codepath, I will support
> that kind of change. But in order to convince me, you are going to have
> to tell me what they are. If there aren't any, then it is wasteful to
> have more than one codepath.
Sorry - I'm not meaning to come across as fixed on a solution here.
But I acknowledge I probably am.
I've profiled local branch creation on the OOo tree and here are some
of the numbers (in ticks) for bzr.dev:
* 91.9k = total
* 30.6k = transform._apply_insertions.
I've headed back towards a single code path in the attached patch.
It's profile numbers are:
* 61.2k = total
* 630 = transform._apply_insertions.
Inside _apply_insertions, I'm still using a fast path for the "create
from scratch" case. Going back to the source of the 30k in ticks
being saved, here's where that time is going:
* 9405 = transform.set_executability
* 7907 = tree.id2path
* 2960 = inventory.make_entry
* 2358 = transform.new_path
* 2124 = progress.update
os.rename is taking 2419 in bzr.dev vs 500+ in my branch, so that's
either a reflection of variation in this area, or perhaps renames
are just quicker when less other stuff is happening to the filesystem?
So it's clear that my change (higher up in _build_tree) in deciding
which files to set the execute bit on is making a difference. But
even removing that completely from the picture, walking 100K files
just takes lots of time (21.2k ticks) vs just walking the
interesting ones (630). That's not to say that tuning/replacing
id2path with something else isn't a good idea, of course - it just
isn't going to get us down to the same place I expect.
Anyhow, my latest code is attached. Beyond the changes to transform.py,
there's also a small optimisation to iter_references. That popped
up in some of my profile runs as being a 5% issue. If you'd prefer me
putting that up separately, or not doing it at all, that's fine.
I've also put things back so that resolve_conflicts is always called
and fixed the issue that was breaking some tests.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 21661 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080530/7fc51383/attachment-0001.bin
More information about the bazaar