Rev graph caching strategy (was Re: trac-bzr performance)

[Alexander Belchenko]

Ian Clatworthy пишет:
> Martin von Gagern wrote:
>> Alexander Belchenko wrote:
>>> Martin, recently in IRC I've asked you about caching. This is what I have in my mind. Glad there
>>> already is some implementation.
>> I remember, and I begin to see the applications...
>> This will need some careful planning, but I guess there might be
>> someinformation worth caching. Will need to think about what and how.
>> And how to notice when caches have become invalid, e.g. by overwriting
>> pushes to some branch.

> I think the right strategy wrt caching is to do it in one plugin and for
> other plugins to leverage that. Otherwise we end up with caching all
> over the place (loggerhead, trac-bzr, qbzr, etc.). That's a problem
> because we'll need to re-optimise each plugin as the core improves:
> caching can be great but also counter-productive. For example, the
> caching in fastimport was essential in the bzr 1.6 days but actually
> slowed things down when the new format arrived. I recently made
> fastimport much faster and less memory hungry by simply disabling it
> recently!

Ian, it seems the problem much complex than that. trac-bzr is not bzr plugin, it's plugin for trac.
And as Aaron noted trac design is hugely different from usual bzr design. So it seems natural that
trac-bzr might need different type of cache.