Alexander Gavrilov writes: > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
