Comment 5 for bug 309374

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 309374] Re: Log performance with stacked branches

btw what parameters did you give log ?

broadly (these don't sum, they are snapshots out of the call graph).
1314 btree nodes read in 212 calls. 24%
however 4.7M nodes examined - 29% of time.
300000 get_parent_map calls.
get_parent_map in iter_ancestry:97K get_parent_map calls 78% of time
filter_fileid_revisions_touching_file: 11%

so in knit.py's get_parent_map there is a function turning 97K external
calls into 190K backing calls. Thats actually reasonable (because its
stacked, and 99% of the history will be in the stacked-on branch
typically.

The most obvious thing: we shouldn't examine all ancestry for this
command (as its clearly per-file).

Secondly, we may be thrashing the B+Tree cache.

I wonder if bzr-revnocache would help.

-Rob