2014-09-10 13:19 GMT+02:00 Richard Hipp <[email protected]>:
> In my measurements, multiple worker threads only provide a performance
> advantage when you are sorting millions of rows. Which is not something
> that happens very often in Fossil.
>
> On the other hand, there is a performance advantage on *all* operations to
> disabling mutexes.
I'm not proposing to enable mutexes, that's what the "serialized" mode
would do. Fossil will use the "multi-thread" mode, which only uses
mutexes for communication BETWEEN threads, which has no
effect if there are no other threads. at least that's how I understand
the multi-thread mode to work.
> So my guess is that the patch above makes things slower, not faster.
> Though, I admit, I have not measured. Have you?
Did some time measurements, and I didn't find any slowdown when
compiling SQLite with SQLITE_THREADSAFE=2 in stead of
SQLITE_THREADSAFE=0. I did various "fossil timeline" measurements,
none of them showed any difference between the two modes,
neither when changing the max number of threads.
So, my conclusion:
- No slowdown is measurable in fossil's "multi-thread" branch.
- No speedup is measurable when setting "max-wthreads" > 0 either.
Still, since "max-wthreads=0" is the default, I don't see any
danger in merging this branch to trunk. I didn't find a query
that showed speedup when using multiple threads, but
that doesn't mean such a query doesn't exist.....
(suggestions welcome!)
I don't see any danger merging this branch to trunk, since
the default setting has the same behavior (and timing!)
as trunk. Whether max-wthreads>0 gives a speedup,
that would be a good test-case for SQLite 3.8.7's
multi-thread support. I could imagine multi-thread
support to be enhanced in future SQLite versions.
It would be good then if fossil could be used
to measure it.
Joe already made some styling improvements to
this branch (thanks, Joe!), in my view it is ready
to be merged to trunk.
Thanks for your attention!
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
