[RFC/PLEASETEST] Per-file graph heads detection during commit for pack repositories.

John Arbash Meinel john at arbash-meinel.com
Wed Nov 14 17:13:54 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Wed, 2007-11-14 at 10:49 -0600, John Arbash Meinel wrote:
>>
>> The callgrind seems to put 98% of the time in bzrlib.graph.heads().
>> I'm
>> actually thinking that part of the problem is that we don't cache any
>> of the
>> graph information, so every call needs to go all the way down and
>> bisect
>> through the index data. I might work up an alternate patch. 
> 
> We don't cache the result of heads, but the graph data itself is cached,
> successive calls won't do IO if the same revisions are accessed.
> However, sum the revisions in the get_parents calls and you'll see a
> large chunk of the problem. A related one is that we make 3 times as
> many get parents calls because we use separate lookups for each
> searcher.
> 
> -Rob

I'm pretty sure this is incorrect. I just sent a email on this. If I add a
cache of revision_id => parents for every call to get_parents() it changes the
time from 73s down to 16s. (Note that it 3s for the file graph version you have.)

I agree about the separate calls issue. One thing I saw on the callgrind is
that 50% of the time is spent in 'find_seen_ancestors'. Which is the call which
cleans up the searcher whenever things are found to converge, IIRC.

I certainly thought it would be better if you had one logical graph that
searchers interacted with. So they could label nodes that they reached, etc,
rather than keeping their own sets/dicts of nodes. I haven't written the code,
though, and IIRC Aaron felt that it was necessary to do it this way because of
the state that they need to keep.

John
=:->


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOyzSJdeBCYSNAAMRAmjwAKDRFkNO+CqQk1JNezAUAQ6+GZWgLwCgsHWy
a87RvW408LMj9akHTLg432Q=
=pxZl
-----END PGP SIGNATURE-----



More information about the bazaar mailing list