On 12/30/19 10:19 AM, Doug wrote:
OK, I get that the definition of the SQLite API is a (large) set of C function
calls. And that changing the way they work under the covers would break
something. (Check out the IDEA below!)
I'm wondering if your use case is - in the same application - that you
dynamically change from option SQLITE_CONFIG_SINGLETHREAD to
SQLITE_CONFIG_MULTITHREAD to SQLITE_CONFIG_SERIALIZED while your application is
running? If that is the case, then your application knows which option to use
dynamically; Otherwise, your application doesn't know and doesn't care which
option is in effect.
I am suggesting that if the we added the global calls to the underlying
functions to the API - that is, the functions that are called by the function
table indirection - then one could code the application to call the underlying
functions. If the application knows it's single-thread, then code it that way
and get a 25% improvement (see the talk). If the application makes the choice
of thread option dynamically, then the penalty for single-thread is at least
double (application choice, SQLite indirection), so calling the (new)
underlying function once you made the choice, performs better for that path. I
grant you that probably will see little improvement on the threaded path.
If you are going to tell me that you need to maintain two versions of your
application if you run it in a single-thread environment or a multi-thread
environment, then let's define the (new) API to use a preprocessor macro to
generate the right code for the option selected based on the values of
SQLITE_CONFIG_SINGLETHREAD, el al. So now you have a single source but multiple
executables corresponding to that source. And the choice of which executable to
use becomes a configuration problem at application deployment time, or at
application run time.
---- IDEA! ----
Thinking about it, I'm surprised that the C API isn't just a set of macros
already. I can visualize a C API composed of a set of macro definitions
_identical_ to the current C function calls. They just use the extra knowledge
of SQLITE_THREADSAFE and other SQLite compiler options to decide what
application code to generate. Then the formal API doesn't change from a coding
point of view. The generated code calls a set of under-the-cover functions
which are not part of the API. The change doesn't require a new layer of
testing; presumably, we already have test cases that test the same code using
different compiler options. What about that?
Best, Doug
One BIG reason the C API can't be made into a set of macros is that the
C API is basically the multi-language API for using the SQLite shared
library in other languages. This requires that the C API functions be
REAL functions that provide entry points into the shared library. It
also, perhaps as a much more minor point, prevents taking the address of
those functions to use in the application either to pass SQLite routines
as call backs or make build your own virtual functions (admittedly, I
don't know of a case where you would really want to do that).
I suspect that by far the vast majority of SQLite uses don't bundle the
SQLite source code into the project, but link to it as an external resource.
Yes, there is perhaps an option to provide some specific configuration
macros to allow SQLite to be optimized when included statically in a
project, but those options shouldn't change the API.
--
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
