> On Dec 25, 2019, at 2:53 PM, Doug <dougf....@comcast.net> wrote: > > 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?
This change would break the API that lets you set concurrency levels per connection; instead, the concurrency would be hardcoded at compile time. _You_ may not be using this API, but there are definitely developers who do. This would especially be a problem for environments where SQLite is provided as a shared library in the operating system (e.g. iOS, macOS). The concurrency level would then be up to the platform vendor, not the application developer. (Unless they bundle their own copy of SQLite in their app.) One possible workaround would be a compile option that enables the direct calls, but which is off by default. People who wanted mutexes but with direct calls could then set that option. > On Dec 25, 2019, at 3:25 PM, Richard Hipp <d...@sqlite.org> wrote: > > 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. Because you'd only be testing one concurrency mode? But there are plenty of existing compile-time options in SQLite; don't you have to test multiple builds of the library to test those? How would this one be different? —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
