Re: [PATCH 0/3] fast textconv

Jeff King <peff@peff.net> writes:

This made me wonder if the end result might be easier to use if the interface does not change "textconv", but adds some property to the filter, i.e. "the output from this filter is stable and it is safe to reuse a cached conversion result for a given blob object", boolean. E.g.

        [diff "jpg"]
                textconv = exif
                textconv_stable = true

and let the calling side handle the caching. I further suspect that an unstable textconv filter would be an anomaly, so this could even be on by default.

If we do so, stock conversion filters people have accumulated in the past could be sped up without any additional change from the end user's side.

I guess that I am suggesting to postpone the potential speed-up that could come from being able to inspect the header information as a separate topic. Besides, some file format has metadata at the end, which won't help you.

About the caching scheme; to help invalidating the cache, it probably is a good idea to use not just the blob object name but also at least the name (command line) of the textconv filter as the key for the caching layer.

Instead of the "textconv_stable" boolean depicted above, you could add a "textconv_filter_version" variable there, compute a hash over blob object name, textconv filter name and textconv filter version, and use that as the key to look into the cache (filters lacking textconv_filter_version would then get no caching, and if you update your "exif" program you bump the "textconv_filter_version" variable).