Re: [PATCH v5 2/3] path: optimize common dir checking

[David Turner <dturner@twopensource.com>]

On Mon, 2015-10-05 at 10:22 -0700, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > For this particular application, where we only have 19 strings to store,
> > I suppose we could tolerate the use of approximately 64k of RAM to store
> > 174 characters worth of strings *if* it would bring us big time savings.
> > But I think we need some evidence of the time savings.
> >
> > If this lookup is really a bottleneck, I bet there are other
> > alternatives that are just as fast as this trie and use less code,
> > especially given that there are only 19 strings that need checking.
> 
> Very good point.  I agree that we need to know that the dumb linear
> scan in the original is on the bottleneck and that any replacement
> is an improvement.

Just did a tiny bit of microbenchmarking:

The trie code is indeed somewhat faster, but it's not the bottleneck in
the git_path family of functions.  The sprintf stuff takes way more
time.  Most callers don't need this functionality (an append would do).

But this is a benchmark of just git_path.  I don't happen to see any
cases where git_path is taking up an appreciable amount of runtime.

I only added this because Junio requested a speedup.  So I am perfectly
happy to drop this patch from the series.