Jeff King <peff@xxxxxxxx> writes: > Running a textconv filter can take a long time. It's > particularly bad for a large file which needs to be spooled > to disk, but even for small files, the fork+exec overhead > can add up for something like "git log -p". Another reason that "log -p" gets benefit from caching is that you would typically end up running textconv twice on the same blob, once when you compare $commit:$path with $commit~1:$path, and again when you compare $commit~$n-1:$path with $commit~$n:$path (assuming that the $path didn't change between $commit~$n-1 and $commit~1). It _might_ give you even better performance characteristics if you noice that you are walking history running many textconv, and cache the textconv result from the "older" (i.e. "one" side) tree in-core, until it is used in a "newer" (i.e. "two" side) tree, at which time you would evict it. -- 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