random commit speed notes:

[Robert Collins]

disabling record_entry_contents by doing
if path != '':
    return

drops our time to 31 seconds on first commit of mozilla

Now the work it saves is:
 - less data in the new basis 
 - no data added to the knits

Disabling it later in the method, after the entry is added the xml, so
we only stop adding data to the knits drops the time to:
34 seconds

Which is what I expected - writing the inventory out is not hugely
expensive.

Heres an important point: The largest win we can make outside of
record_entry_contents is 30 seconds.

gzipping the contents of mozilla.tar takes my machine 36 seconds (this
is user time figues, not wall clock - obviously latency to disk will
impact wall clock.

So, if we were to be maximally efficient at record_entry_contents today,
we should have a total commit time of 64 seconds; but the best I've seen
so far is instead 143 seconds. 

Ian - I know you see some 20-40 second win with your iter changes based
commit; I'm really curious where they come from, because as far as I can
tell the time outside of record entry contents is not even 40 seconds
long :). It's always smelt strange to me to see so big a win, I'd really
like to understand more clearly what you are seeing. Perhaps profiling
with the sort of crippled record_entry_contents I'm describing may help
us there.

I plan to spent most of my time working on making record entry contents
fast - shaving off time, wastage, and getting rid of the triple
handling. Did you know that we spend 5% of commit just checking that the
output of file.readlines() is a bytestring and correctly split on
newlines? E.g. second guessing python.

Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070906/aae6eb73/attachment.pgp