Re: Caching last date/time string on loading

On 10/3/20 12:36 PM, Robert Krawitz wrote:
> I'm getting maybe 8% improvement on startup by caching the most recent date/time string when loading
> image, and returning the same date rather than re-parsing it.  It's taking about 8.1 seconds vs. 8.8
> to start up now.
> 
> This is going to vary a lot depending upon the composition of someone's database.  If someone has a
> database with a lot of older images without EXIF data where someone might have manually assigned a
> fixed date, or uses continuous bursts frequently with a fast camera, or shoots in RAW+JPEG mode, the
> benefit could be considerable (as in my case).  If not, there will be a small overhead (I'd expect
> it to be very small, since it's just one uncontended mutex and one string comparison).  I have a
> total of 386253 image files with 172370 unique dates, so I'm saving more than half the conversions
> by doing this.

I've pushed this, and a similar change on the save side (plus avoiding a whole bunch of constant
string constructors) to the load-save-cache branch.