On Sat, Jan 4, 2020 at 2:59 AM Howard Chu <h...@symas.com> wrote: > Keith Medcalf wrote: > > > > Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s) > performance increase. > > Changing the threading mode or the indirection level of the mutexes > calls seems to have no significant effect. > > > Goes to show - publishing benchmark results without investigating why they > are what > they are is mostly pointless. When you suspect mutex contention is a > significant > factor, you should use something like mutrace to confirm your suspicion > first. > > Fundamentally there ought to be no performance difference between running > a 64-threaded > server on a 64-threaded CPU vs 64 single-threaded processes. In practice, > the single > process with 64 threads ought to be slightly faster, due to less context > switch overhead > between threads, but if nothing else in the system is contending for CPU > then context > switching shouldn't even be an issue. >
but, if the mutex lock always does a 'sched_yield' when the locking fails, then a failure to lock isn't just a stutter in the thread, but can result in at least 2 more context switches every time. Probably something simpler like a simple InterlockedExchange() call in a loop could maintain locking, and affect performance much less; since it sounds like the actual lock duration is really only a few clocks anyway. Could wish there was a way to pause execution without giving up execution context... > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
