[odb-users] "threads-sqlite" test case takes an extraordinary
long time to execute
odb at a-cunningham.com
Thu Jul 14 14:16:11 EDT 2016
Not surprisingly, conn_.wait() is where all the "waiting" time is spent.
For example, this is one particular area where a lot of "waiting" is
occurring.... the top of this stack is
650 #ifdef LIBODB_SQLITE_HAVE_UNLOCK_NOTIFY
651 sqlite3* h (conn_.handle ());
652 while ((e = sqlite3_step (stmt_)) == SQLITE_LOCKED)
654 if (sqlite3_extended_errcode (h) !=
657 sqlite3_reset (stmt_);
658 conn_.wait ();
661 e = sqlite3_step (stmt_);
On Thu, Jul 14, 2016 at 9:52 AM, Andrew Cunningham <odb at a-cunningham.com>
> With my build of SQLite , using all your SQLite #defines, the test ran in
> 1243.1s. ( not quite as long as I originally said, but still unexpectedly
> It's pretty clear based on profiling that the time is spent in
> synchronization objects waiting on disk operations to complete.
> I changed the Journal mode
> "PRAGMA journal_mode = MEMORY"
> and the execution time was 342s (4x faster). Still surprisingly long. The
> CPU is idle nearly 95% of the time.
> On Thu, Jul 14, 2016 at 8:52 AM, Boris Kolpackov <boris at codesynthesis.com>
>> Hi Andrew,
>> Andrew Cunningham <Andrew.Cunningham at esi-group.com> writes:
>> > I am using SQLite "sqlite-amalgamation-3120200"
>> I checked and we are (still) using 3.7.5. You can try that in case
>> SQLite folks broke something.
>> > The only additional flag when compiling SQLite is
>> > "SQLITE_ENABLE_UNLOCK_NOTIFY"
>> We have quite a few more defines. Check SQLite the project files in the
>> etc/ directory in libodb-sqlite.
More information about the odb-users