• 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, SQLite, and Housekeeping
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data, SQLite, and Housekeeping


  • Subject: Re: Core Data, SQLite, and Housekeeping
  • From: Ben Trumbull <email@hidden>
  • Date: Wed, 5 Mar 2008 18:23:56 -0800

If you have any performance data showing problems with internal db fragmentation (i.e. sqlite3 dbname 'vacuum' fixes it, but cp doesn't), we'd love to hear about it.

Thanks, Ben, for this informative response. So what you're saying, in summary is:


1 - Vacuuming on every save is inefficient to the point of silliness.

Yup. Kinda defeats the point of having incremental load/saves in a transactional persistent store.


2 - For anything but very large databases and/or running on slow hardware, the benefits of vacuuming is minimal anyway.

Your mileage may vary as to what exactly constitutes a "large database", but for smaller databases and faster hardware there is a diminishing return.


Certainly, there are cases where vacuuming makes sense. One might perform a manual vacuum after a initial import, especially for a large database (i.e. the cost for the vacuum is balanced by many future queries) or after a significant operation like upgrading to a new version.

To that, I pose another question: Why, then, does it make such a huge difference when I run the vacuum command against Mail's database? After just a month of usage, Mail seems sluggish when switching between various folders, but once I run the vacuum command, it is once again snappy?

Well, many people run Mail constantly so the database is experiencing a significant amount of churn over a month, and the envelope index is often quite large. A month of incessant use is a nice chunk of uptime.


You can see I/O performance using the fs_usage command. If you're experiencing a large amount of fragmentation, the response times on the I/Os will increase as the drive has to seek more.

You can compare the performance gain from vacuuming the Mail index to simply using cp to create a new index file. If the drive has a nice chunk of free space, OSX will try to keep the file's blocks close together when creating the copy.

The point at which a manual vacuum pays for the cost of rewriting the file depends on a lot of factors.
--


-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


References: 
 >re: Core Data, SQLite, and Housekeeping (From: Ben Trumbull <email@hidden>)
 >Re: Core Data, SQLite, and Housekeeping (From: "I. Savant" <email@hidden>)

  • Prev by Date: Re: NSStream SSL Help
  • Next by Date: Re: Undo and Core Data issue
  • Previous by thread: Re: Core Data, SQLite, and Housekeeping
  • Next by thread: [Job Posting] Full Time Cocoa Developer
  • Index(es):
    • Date
    • Thread