On 12/25/19, Doug <dougf....@comcast.net> wrote: > Richard, can you please explain each of these? > > 1. API break > I wrote an application in Qt which uses SQLite. Therefore, I invoke SQLite > functions with some wrapper. For a 9% performance improvement in SQLite > using the direct call versus indirect call (as discussed in the talk), > cannot the wrapper functions be changed so my application doesn't know the > difference?
You can completely disable all of the mutexes by compiling with SQLITE_THREADSAFE=0. That works fine, as long as you don't use any SQLite API in more than one thread at a time. And it does, definitely, make SQLite run faster. If you feel like you have to use threads, then you can run SQLite in multi-thread mode and most of the mutex calls will be omitted. Multi-thread mode allows multiple threads to use SQLite at the same time, as long as every thread is using a different database connection. If you run in serialized threading mode, then there will be many mutex calls. There is no way around that. Threading modes described here: https://www.sqlite.org/threadsafe.html > > 2. Render SQLITE untestable > Does that mean that you are doing whitebox testing? Surely, all the > thousands of queries vs responses are blackbox, not whitebox. Why would > changing indirect calls to direct calls render SQLite untestable? By "untestable" I mean that we would be unable to obtain 100% MC/DC (essentually 100% branch test coverage) in an SQLite compiled as for delivery. We go by the philosophy that "If it isn't tested, then it doesn't work" and so if there are branches that are unreachable by our tests, then SQLite is "untestable". We also go by "fly what you test and test what you fly", so adding a compile-time option that allows mutex calls to be intercepted and redirected in testing builds but not in release builds won't work for us. > > 3. Unable to replicate performance gains > This says to me you actually made the change suggested. And then you ran a > test suite against the amalgamation. And you actually measured the result. > How can you have done that if such a change renders SQLite untestable? And > (sneaking a peak at the talk again re performance measurements), what did > you use to measure the results? > The video provided details on what they did. I could not find any performance improvement by making mutexes direct calls instead of indirect calls. Maybe I did something wrong. Maybe it depends on your compiler and or optimization options and I didn't use the right combination. Maybe they are measuring performance differently than me. (I use CPU cycle counts measured by valgrind.) Maybe the team that studied this made a mistake in their testing and using indirect calls to mutexes really doesn't matter that much after all. Maybe the problem is some combination of all of the above. I don't know. If you want to try to replicate the performance improvement yourself, and report your detailed findings on this mailing list, you are welcomed to do so. If you have a reproducible test case - perhaps we will go in and provide a compile-time option that makes SQLite run faster in intensely multi-threaded applications at the expense of also rendering it untestable -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
