As a side note: I've compiled some performance data and published them as an article on my blog:
http://manski.net/2012/10/01/sqlite-performance/ Do these result seem to be ok? - Sebastian On Mon, Sep 24, 2012 at 5:02 PM, Olaf Schmidt <s...@online.de> wrote: > Am 24.09.2012 11:26, schrieb Sebastian Krysmanski: > >> Ok, I tried that. It definitely improves performance when using a lot >> threads (15+)... >> > > So I take it, that your last posted result here was using a > shared cache (in case of the multiple connections): > > > ------------------------------**------------------------------**------ >> SELECT_COUNT: 133,333 >> THREAD_COUNT: 15 >> Testing with one connection (ReadWrite) and filled table... >> Elapsed: 12.3 s (162,647.6 stmt/sec) >> Testing with multiple connections (ReadWrite) and filled table... >> Elapsed: 12.7 s (157,324.1 stmt/sec) >> > > Whilst the following result (from an earlier of your replies), > was not using a shared cache (instead using separate caches > per thread in case of the multiple connections): > > > > ------------------------------**------------------------------**------ > > SELECT_COUNT: 133,333 > > THREAD_COUNT: 15 > > Testing with one connections (ReadWrite) and filled table... > > Elapsed: 9.5 s > > > Testing with multiple connections (ReadWrite) and filled table... > > Elapsed: 51.2 s > > Possible things which could explain that (because it differs from > my results considerably) are potentially: > 1. the setting for: PRAGMA read_uncommitted > 2. the implementation of the Busy-Handler > > Ok, just looking what my settings were for case 1... > and 'PRAGMA read_uncommitted' was at Zero, so this case > can be dumped I think. > > So I suspect the latter case ... > Which Busy-Handler do you use, the built-in one? > called up per: sqlite3_busy_timeout(sqlite3*, int ms) > > Or your own implementation? > > In my own BusyHandler (I'm dealing only with Windows here) > my first (few) "wait-fast" calls in the Busy-WaitLoop are always: > Sleep 0 > > which according to the MSDN: > > http://msdn.microsoft.com/en-**us/library/windows/desktop/** > ms686298(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx> > "relinquishs the remainder of the threads timeslice", but > will try to return as soon as possible in this case. > So, if you implement your own Handler (for Windows), > calling Sleep 0 first (a few times) may worth a try, > so that you give the pausing thread the chance, to > take up its work much earlier, in case the cause for > the blocking was only a really short one (on some > other thread). > > Also worth noting in this regard is, that the TimeSlice for > low values as e.g. > Sleep 1 > doesn't (always) send the thread sleeping for "exactly" 1 msec - > the time until the thread resumes its work depends in this > case (for such low values) on the settings which were > (only potentially) performed earlier with timeSetEvent... > > By default Windows has a "Tick-Interval" of about 12-15msec > (as the minimum-sleep-time for millisec-values > 0). > But this "Tick-Interval-granularity" is explained also in > the 'Remarks'-section of the MSDN-page for Sleep(). > > Olaf > > > > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
