[odb-users] "threads-sqlite" test case takes an extraordinary long time to execute

[Andrew Cunningham]

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
odb::sqlite::update_statement::execute

650    #ifdef LIBODB_SQLITE_HAVE_UNLOCK_NOTIFY

651            sqlite3* h (conn_.handle ());
652            while ((e = sqlite3_step (stmt_)) == SQLITE_LOCKED)

653            {
654              if (sqlite3_extended_errcode (h) !=
SQLITE_LOCKED_SHAREDCACHE)
655                break;
656
657              sqlite3_reset (stmt_);
658              conn_.wait ();
659            }
660    #else
661            e = sqlite3_step (stmt_);
662    #endif


On Thu, Jul 14, 2016 at 9:52 AM, Andrew Cunningham <odb at a-cunningham.com>
wrote:

> 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
> long)
>
> 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>
> wrote:
>
>> 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.
>>
>> Boris
>>
>
>