On Sat, Sep 4, 2010 at 2:23 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> SQLite also does a stat call per statement, unless there is already a shared
> lock open, just to check if there is no other process that opened a
> transaction.
> (On Windows this specific stat to check for other processes operating on the
> same db is the performance killer for svn status: Just this stat takes more
> than 50% of the total processing).
Aha. Adding exclusive locking into our pragma
[http://www.sqlite.org/pragma.html] calls in "svn_sqlite__open":
"PRAGMA locking_mode=exclusive;"
brings the time for "svn st" down from 0.680 to 0.310 seconds. And,
yes, the I/O percentages drop dramatically:
~/Applications/svn-trunk/bin/svn st 0.37s user 0.31s system 99% cpu 0.684 total
~/Applications/svn-trunk/bin/svn st 0.26s user 0.05s system 98% cpu 0.308 total
I *think* we'd be okay with having Sqlite holding its read/write locks
for the duration of our database connection rather than constantly
giving it up and refetching it between every read and write operation.
As I read the sqlite docs, we should still be able to have shared
readers in this model - but, it'd create the case where there were
idle shared readers (due to network I/O?) would block an attempted
writer. With a normal locking mode, a writer could intercept a reader
if it were idle and not active. However, I'd think our other locks
would interfere with this anyway...so I think it'd be safe.
Thoughts? -- justin
Received on 2010-09-04 18:33:56 CEST