[MERGE] Only loop graph.iter_ancestry once when running "bzr log FILE"

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Gary van der Merwe wrote:
>> I thought this was going to increase the speed of "bzr log FILE" alot,
>> but it only made it a bit faster. I did not realize that the loading
>> of the graph is cached.
> 
>> lifeless said I should still submit.
> 
>> Quote from Irc:
>> <lifeless>	 the index layer does have a cache of its own, and the
>> majority of the cost of traversing is disk io and parsing, yes.
>> <lifeless>	 but with a big enough data set, the cache can be
>> exhausted, which would lead to duplicate IO
> 
> Also, Graph instances will have their own cache via
> CachingParentsProvider, and that will not expire for the lifetime of the
> Graph.
> 
> Aaron

Well, actually Repository.get_graph() injects the
CachingParentsProvider, which is something I'd really like to get rid
of. We do it mostly because of poor performance in GraphIndex caching.
So with BTree we will likely be fully away from it. (GI *has* gotten
better, but still far worse than a simple dict lookup, I haven't
re-evaluated it recently, though.) I will agree it is inefficient to
cache 2x, especially with the new buffer_all changes (so we are likely
to have everything cached in a simple dict at the GI layer, and then we
put another one on top of that).

Mostly, I was just planning on waiting for BTree indexes to be
available, and having BTreeRepository.get_graph() not inject a
CachingParentsProvider.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjGgMYACgkQJdeBCYSNAAMWwgCgo3DBg9k7QTcATvx3j2IfjkvM
EdEAnA2yewFuXYxlty2a3E20pS5P0b3+
=zQK8
-----END PGP SIGNATURE-----