4 ms·
Way back in the day, like a decade or more ago when I was working on Aperture, we increased the speed of the database by dropping CoreData and moving to an embe
by spacedcowboy 3y ago
Way back in the day, like a decade or more ago when I was working on Aperture, we increased the speed of the database by dropping CoreData and moving to an embedded SQLite with tuning set up for the application.
We had a test database of 1,000,000 images, each with large amounts (several hundred) of metadata items - EXIF and the like, all of which could be queried. We had a target time of 2 seconds to get any query back. Most of the time, we hit that mark using the raw SQLite database approach.
So this was:
- On far older hardware, we still used spinning rust for $deity sake...
- Seems like much more data
- Seems like much more metadata
And it was still very fast (relatively speaking - a couple of seconds is still a long wait-time, and then there was all the UI overhead on top).
I think the author might be missing a trick or two when running SQLite, as mentioned in their write-ups, we found it faster than the filesystem as a storage medium...
- traceroute66 3y ago> when I was working on Aperture As a long-term Aperture user, I concur with the above sentiments. It was an impressive real-world use of SQLite by Adobe. Hence I agree with the conclusion that if SQLite is "slow" its usually a PBCAK error.
- jitl 3y agoAperture was Apple’s pro competitor to Lightroom, not made by Adobe.
- traceroute66 3y ago> Aperture was Apple’s pro competitor to Lightroom, not made by Adobe. My bad, apologies. Although in my defence, Lightroom also uses SQLite as backend, although clearly I'm not sure how extensive it is compared to Apple Aperture.