Interestingly enough, I experienced this behavior in my latest app which doesn't use Core Data. It uses SQLite directly instead. I recalled I had experienced this a long time ago (years ago) and someone (I don't remember who and where) mentioned a solution/ workaround/hack, which involves reading the file. Let's call this function warmUpFile():
This is treating the symptom instead of the disease of doing far too much I/O. Ruotger has a lot of more valuable optimization work to do first, before worrying about whether or not it makes sense to warm up the UBC cache.
Nearly all the time, it makes more sense to perform fewer I/O operations, or otherwise reduce the quantity of I/O or improve their locality of reference. This kind of hack put a lot more memory pressure on the system, and is prone to induce VM paging. That would be even worse for performance.
It's possible for SQLite databases to become fragmented, both on disk in traditional file fragmentation and internally as tables grow and shrink, they can lose their own locality of reference (imagine like malloc heap fragmentation). Fragmented database files can be reconstructed with better internal locality by using the vacuum pragma. This can be extremely expensive for very large files, however. File system fragmentation is usually handled at the same time, or by recopying the file elsewhere. Unless you are low on free space, in which case you are SOL. HFS+ volumes provide better performance with more free space. I'm not certain what the specific recommendations are, but I believe people are encouraged to keep at least 10% of the disk space available for optimal performance.
It's possible to reduce internal db fragmentation by avoiding the auto- vacuum pragma and using incremental vacuum instead. Core Data does this now for all its clients. In general, we try to tune database performance "out from underneath" our clients by adopting new features both in SQLite and in Mac OS X.
- Ben _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
