Going back to 2007, so can't remember super clearly, but IIRC the db was a sqlite like thing and all info about everything was stored in this, and it was vulnerable to corruption, plus all versions and thumbnails were mixed together with original image files - a total mess. The digital photo management landscape wasn't so mature then, and some people trusted Aperture with their original images whereas later versions allowed or encouraged people to keep their "masters" elsewhere.
Because the whole thing was as slow as a slug dragging a ball-and-chain, pre-SSD, issues with that filesystem or master database were sometimes mistaken for just general slowness. I jumped to Lightroom faster than you could say Gordon Parks.
Aperture 1.0 was very slow. The stories I could tell about its genesis...
I came on board just before 1.0 release, and for 1.5 we cleaned things up a bit. For 2.0 we (mainly I) completely rewrote the database code, and got between 10x and 100x improvements by using SQLite directly rather than going through CoreData. CoreData has since improved, but it was a nascent technology itself back then, and not suited to the sort of database use we needed.
The SQLite database wasn't "vulnerable to corruption", SQLite has several articles about its excellent ACID nature. The design of the application was flawed at the beginning though, with bindings used frequently in the UI to managed objects persisted in the database, which meant (amongst other things) that:
- User changes a slider
- Change is propagated through bindings
- CoreData picks up the binding and syncs it to disk
- But the database is on another thread, which invalidates the ManagedObjectContext
- Which means the context has to re-read everything from the database
- Which takes time
- By now the user has moved the slider again.
So: slow. I fixed that - see the other post I made.
Thanks for the lovely insight, super interesting - I don't think I made it to Aperture 2 - but sounds like some unusual decisions made in that editing process. I suspect, based on my own history with disk problems, that the filesystem issues that would regularly pop up and not dealt with by your average technically-over-trusting student were the root cause, but exacerbated by the choices of image management and application speed.
Because the whole thing was as slow as a slug dragging a ball-and-chain, pre-SSD, issues with that filesystem or master database were sometimes mistaken for just general slowness. I jumped to Lightroom faster than you could say Gordon Parks.