• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data dog-slow when using first time after boot
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data dog-slow when using first time after boot


  • Subject: Re: Core Data dog-slow when using first time after boot
  • From: Ben Trumbull <email@hidden>
  • Date: Wed, 19 Aug 2009 13:20:13 -0700

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 (email@hidden)

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:
This email sent to email@hidden


  • Prev by Date: Re: Core Data dog-slow when using first time after boot
  • Next by Date: Re: Core Data dog-slow when using first time after boot
  • Previous by thread: Re: Core Data dog-slow when using first time after boot
  • Next by thread: Starting editing for a Row as soon as it is Added.
  • Index(es):
    • Date
    • Thread