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 (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 [EMAIL PROTECTED]
