Re: [sqlite] Performance...there must be a reason
Avner Levy wrote:
I've downloaded the latest src and compiled the new version 2.8.11 on
Solaris 2.8 and tried to check the lock fix with the threadtest1.c.
The output was as followed:
===
2.testdb-4: command failed: INSERT INTO t2 VALUES(58,116,3364); -
database schem
a has changed
===
If you change the "if" on line 147 to a "while", I think
it will clear this problem.
*** threadtest1.c 14 Jan 2004 03:32:38 - 1.1
--- threadtest1.c 21 Jan 2004 13:34:04 -
***
*** 144,150
va_end(ap);
if( verbose ) printf("EXEC %s: %s\n", zFile, zSql);
rc = sqlite_exec(db, zSql, 0, 0, );
! if( rc==SQLITE_SCHEMA ){
if( zErrMsg ) free(zErrMsg);
rc = sqlite_exec(db, zSql, 0, 0, );
}
--- 144,150
va_end(ap);
if( verbose ) printf("EXEC %s: %s\n", zFile, zSql);
rc = sqlite_exec(db, zSql, 0, 0, );
! while( rc==SQLITE_SCHEMA ){
if( zErrMsg ) free(zErrMsg);
rc = sqlite_exec(db, zSql, 0, 0, );
}
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Performance...there must be a reason
I've downloaded the latest src and compiled the new version 2.8.11 on Solaris 2.8 and tried to check the lock fix with the threadtest1.c. The output was as followed: === 1.testdb-1: START 2.testdb-1: START 1.testdb-2: START 2.testdb-2: START 1.testdb-3: START 2.testdb-3: START 1.testdb-4: START 2.testdb-4: START 1.testdb-5: START 2.testdb-5: START 2.testdb-4: command failed: INSERT INTO t2 VALUES(58,116,3364); - database schem a has changed === Another run gave: === 1.testdb-1: START 2.testdb-1: START 1.testdb-2: START 2.testdb-2: START 1.testdb-3: START 2.testdb-3: START 1.testdb-4: START 2.testdb-4: START 1.testdb-5: START 2.testdb-5: START Alarm clock === Did anyone tested this on Solaris ? Your input is very important to me (I'm trying to find out if this version will solve the multi-threading database access problem). Thanks in advance, Avner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] Performance...there must be a reason
> -Original Message- > From: Tim Anderson [mailto:[EMAIL PROTECTED] > Sent: 17 January 2004 22:45 > To: [EMAIL PROTECTED] > Subject: [sqlite] Performance...there must be a reason > What I can't work out is why. The same database is used. The > same Sqlite dll is used. The same pragmas are executed. The > compiler options are identical (unless I've missed a > directive lurking in the code somewhere). > > Just wondering what I'm missing? Solved. The reason is that the faster wrapper issues a BEGIN TRANSACTION on app startup and leaves the transaction open until an update is required. This makes hardly any difference on WinXP and an astonishing difference on Win98. It is no good surrounding the SELECT statement with BEGIN TRANSACTION and ROLLBACK (or COMMIT); this takes just as long. You have to leave the transaction open. Logically a transaction is never necessary for a read-only SELECT. So in a sense it should make no difference, and on WinXP that's the case. But in my test installation of Win98 I get a huge speed-up. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Performance...there must be a reason
I'm trying out two Delphi wrappers. One is the SQLite for Delphi project here: http://sourceforge.net/projects/sqlite4delphi the other is the much simpler wrapper here (warning: this links to the actual zip file): http://myhtpc.net/sqlite/sqlite-delphi.zip I actually want to use the simpler wrapper but I can't work out a performance issue. On Win XP the 2 wrappers have similar perf. On Windows 98 (ugh) the SQLite for Delphi project populates a dataset approximates 3 times faster (not a small difference). I thought at first this was because the simple wrapper uses sqlite_get_table(). So I changed it to use a callback instead. I then tuned the callback in various ways. By using a profiler, I can see that my implementation of the callback is about 4 times quicker than the other (not surprising, as it doesn't implement a fully-fledged Delphi dataset). Yet overall it remains 3 times slower. All the profiler tells me is that the call to sqlite_exec takes 3 times longer (I haven't tried to profile the Sqlite dll as yet). What I can't work out is why. The same database is used. The same Sqlite dll is used. The same pragmas are executed. The compiler options are identical (unless I've missed a directive lurking in the code somewhere). Just wondering what I'm missing? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
