Am 24.11.2005 um 10:43 schrieb ozemail (pcferrett):
I have an app that has been refined for some time using sqlite, to
a performance level that I was fairly happy with. That was running
MacOS 10.2, with sqlite 3 (it was around 3.23 I think).
I have recently installed MacOS 10.4 (Tiger) and though it comes
with sqlite3 (3.1.3), I installed the latest version (3.2.7) anyway.
The app is now very sluggish. Using the Saturn profiling tool (I
believe this is a GUI to the gprof binary), it appears that the
sluggishness is to the sqlite calls. For example, one call to
sqlite3_exec takes 1000 milliseconds! This is for a straight
forward update t set a = b where x = y type of call.
I have tried removing the 3.2.7 library and linking to the built in
library (3.1.3). It makes no difference.
The performance is still slow whether compiling using development
or deployment build styles.
I should also mention that the previous working (wrt performance)
version was built using Project Builder, whereas this version is
built using XCode that comes with system 10.4. The performance is
the same for whether XCode uses the original format or 'upgraded'
to native format.
Any tips to resolve the poor performance appreciated.
Peter,
no hot resolution tip here, but a couple of points you may want to
investigate:
- Are you sure it's related to your move to Mac OS X 10.4?
- Did you try the same query with the same database in your 10.2 build?
- If the updated app is still running on 10.2 - what are the results
if running on 10.2?
- If it's related to 10.4 - are you sure no other background service
is doing disk i/o (spotlight's comes to mind)?
- Did you try the same query/queries with the sqlite3 commandline
executable for comparison?
- Since apparently you're not using make to build sqlite: when you
build with deployment build style, did you define NDEBUG=1 ?
BTW: we're using sqlite 3.2.7 on 10.4 and I don't see this kind of
sluggishness, but anyway sqlite performance certainly also depends on
the data & schema of the database being used, so results can't be
compared unless the same database is used...
</jum>
