[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Worried about single-db performance

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Sat, 4 Sep 2010 09:33:17 -0700

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

This is an archived mail posted to the Subversion Dev mailing list.