[MERGE][1.0] Graph.heads() optimization... 1500 times faster

Robert Collins robertc at robertcollins.net
Thu Dec 6 23:37:38 GMT 2007



> So, the way it is written, Provider.preload_parents() is supposed to return a
> set of revisions that it could not preload. The idea is for
> StackedParentsProvider which will ask all its providers to preload revisions
> that it wasn't able to get from the first one. Which seemed to make sense when
> you are asking questions between 2 pack repositories. 3ms is ~10% slowdown for
> knits, and is probably slightly slower for packs. But I have the feeling that
> 3ms on some operations is greatly offset by the speedup on others.
> 
> With these changes, we might want to go back to not using the per-file graph
> for heads(). At the very least, I think it is something we should re-evaluate.
> Having a heads() search drop 30x on Knit repositories, and 1524x on Packs is
> something worth triggering a re-evaluation of paying for IO versus in-memory
> processing.

Nice :)

I don't know that the preload stuff is needed, simply trying in the
faster repo for X parents, and trying the missed in the next repo in the
stack should be enough; it seems like its a smaller number of concepts
to me.

The way I approached things when I was last fiddling with this was to
decouple searcher's next() from updating. So you could do

search.get_next_query for the searches
then
self.get_parents(query_revisions)
for search in searches:
    search.update(query_result)


Just a thought.

-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/20071207/90a50fef/attachment.pgp 


More information about the bazaar mailing list