Alexander Gavrilov writes:

quoted text
> > And if [tcl_encoding] is slow, then it should have a cache.  There's
> > only likely to be at most 2 or 3 values it gets called for, and it's
> > a constant function.
> 
> In git-gui the slowdown appeared during the construction of the menu
> listing all available encodings, so a simple cache would not have helped. 
> I  reimplemented it using a lookup table to resolve aliases (constructed
> on the first run). But it can be thought of as a precalculated cache.

Hmmm, one that uses more time and memory than it needs to for gitk's
use...  I guess it's not a lot, but it still seems unnecessary, unless
you can see a need for a menu of encodings in gitk.

quoted text
> > At this point, what I think I might do is apply your set of patches
> > (but with 2/4 and 3/4 folded into a single patch) and then go through
> > and do another commit that addresses the concerns I've raised.  OK?
> 
> Maybe I should resend the patches, scrapping path_encoding_cache,
> and adding the optimized version of tcl_encoding?

OK.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html