On Sat, Sep 4, 2010 at 2:23 AM, Bert Huijben <b...@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
