[Monotone-devel] Re: A thought on improving monotone percieved performance

[Bruce Stephens]

"Joel Crisp" <address@hidden> writes:

[...]

> Would it make sense to provide a monitor for files under monotone
> control which would queue a changed file for a low prioirty background
> task to fingerprint it into a cache of current fingerprints? Then come
> a commit etc operation monotone could first check the cache of
> fingerprints and not have to recalculate them during the operation.

My hunch is that it's not worthwhile.  Presuming inodeprints, you'd be
saving a stat() of every file followed by a hash of apparently changed
files (well, you'd be moving the hashes earlier).  I'd guess those
aren't that significant, most of the time.  It shouldn't be hard to
measure, so you could get some indication of the available savings
fairly easily, I should think.