Jeff King <peff@xxxxxxxx> writes:
> The speedup is purely from caching; I am not using the "we only need to
> read the first part of the file" optimization.
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).
--
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