Because a simple test with using this lock with status shows a 70% performance increase on Windows.
You can't get to this speed with just removing 50% of the info queries and Philips tests showed that this is probably the only way to get back at 1.6 status performance. Bert ----- Oorspronkelijk bericht ----- Van: Hyrum K. Wright <[email protected]> Verzonden: dinsdag 7 september 2010 20:11 Aan: Greg Stein <[email protected]> CC: [email protected] Onderwerp: Re: svn commit: r992390 - in /subversion/trunk/subversion: include/private/svn_sqlite.h libsvn_subr/sqlite.c libsvn_wc/wc_db.c libsvn_wc/wc_db.h On Tue, Sep 7, 2010 at 1:08 PM, Greg Stein <[email protected]> wrote: > On Fri, Sep 3, 2010 at 13:34, <[email protected]> wrote: >> Author: rhuijben >> Date: Fri Sep 3 17:34:52 2010 >> New Revision: 992390 >> >> URL: http://svn.apache.org/viewvc?rev=992390&view=rev >> Log: >> Add a few helper functions to allow experimenting with SQLite operations >> inside SAVEPOINTs. This allows taking out a shared read lock for longer than >> the duration of a single SQLite statement, which gives a huge performance >> boost in some hacky tests. (Especially with SQLite 3.7 and on Windows, where >> some of the WAL code slows down SQLite more than it used to do in 3.6) >> >> * subversion/include/private/svn_sqlite.h >> (svn_sqlite__with_lock): New function. >> >> * subversion/libsvn_subr/sqlite.c >> (svn_sqlite__with_lock): New function. >> >> * subversion/libsvn_wc/wc_db.c >> (with_sqlite_lock_baton): New struct. >> (call_sqlite_lock_cb): New function. >> (svn_wc__db_with_sqlite_lock): New function. >> >> * subversion/libsvn_wc/wc_db.h >> (svn_wc__db_with_sqlite_lock): New function. > > Why is this part of the WC_DB interface?!? I see no reason to expose > sqlite to callers of the DB. Let alone mechanics such as locking... +1 -Hyrum
