quark at fb.com
Thu Sep 29 11:04:42 EDT 2016
Excerpts from Jun Wu's message of 2016-09-28 20:22:54 +0100:
> > If it does not need adjustment, the changelog.i walk handles that case
> > in a couple milliseconds. It's the changelog.d walk that we want to
> > avoid (where it looks at the contents of each commit), and the
> > filectx:[linknodes] cache means the .i case will work in the vast
> > majority of cases.
> IIUC, this requires a linkrev (that the walk of .i will encounter) to be
> existed in the map. Otherwise, we fallback to .d walk. This means, if the
> user logs / annotates random files that they didn't touch for the first
> time, it's likely we still need the .d walk.
I think I made a mistake here. The current code already has logic to try .i
first, .d next. So assuming linkrev is accurate / unique, the perf is not a
big concern. An extra on-demand built map may only help with relatively rare
cases where the linkrev is not unique and is locally generated - seems not
common to me. I will try to get more real world perf data to see if it is
really a problem.
More information about the Mercurial-devel