Re: [Core Data] Improve save performance ?
Re: [Core Data] Improve save performance ?
- Subject: Re: [Core Data] Improve save performance ?
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 16 Jan 2006 15:57:52 -0800
On Jan 16, 2006, at 3:01 PM, Eric Morand wrote:
- SQLite : around 0.450 second
- XML : around 0.005 second !!!
In my case an XML persistent store is around 100 times faster than
SQLite !!!??? Is this normal ?
More likely than not, the problem has to do with SQLite's desire to
ensure that the bytes are actually written through to the drive
platter. fsync() does not do that; not on Mac OS X, not on Linux,
nor on any other Unix platform.
Instead, SQLite sends a F_FULLFSYNC request down to the kernel. This
causes the kernel to flush all buffers to the drives and causes the
drives to flush their track caches. Without this, there is a
significantly large window of time within which your data is going to
be sitting in volatile memory.
Ridiculous Fish has a nice writeup on the whole subject, including
links to some relevant discussions in other forums:
http://ridiculousfish.com/blog/?p=17
The same calls are not made for XML or Binary stores. Since they are
atomic, the chance for data loss that involves corruption of the file
is a lot less, especially since the writes are typically atomic and
involve keeping the old file around.
Since SQLite is updating part of a file and loss of that partial
update would be catastrophic, Core Data (through SQLite) goes to
greater lengths to ensure that the bytes are really written.
Unfortunately, there is no way to flush the track cache for just one
file. It is an all or none kind of deal.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden