On 8/8/06, Daniel Önnerby <[EMAIL PROTECTED]> wrote:
I'm just a bit curios if it would be possible to make like a C precompiler or a macro of some kind that compiles/interpret the SQL-statements to bytecode just like the sqlite_prepare does but does this when compiling/precompiling your application instead of at runtime. Since most application written in C/C++ use static SQL-statements (unless you are building your SQL-strings on the fly) and then bind the values, I guess there would be several benefits for your compiled application: * Faster: Since the SQL-statement is already interpreted. * Smaller (not that sqlite needs to be smaller): The executable does not need to contain the part of sqlite that interprets the SQL-statements since this was made at compile time.
Now the cons: * Hardcoded to a specific SQLite version. Even if the *undocumented* API doesn't change on the next version, there's a very good chance it will latter. * Probably not smaller on the easy way.. If you have two pre-compiled statements, it would need a smart pre-compiler to know what can be shared and what can't, implying a level of complexity that maybe doesn't gain nothing. * You can already do the same (with the same problems). By looking at the explain output you can hardcode the same yourself, without the need of a pre-compiler that will need to be constantly up-to-date * If your queries are known at start, you can even forget about SQLite. If you know what you need to do (so, don't need the sqlite library linked, but just a subset of it), maybe it would be best to just call functions and optimize them with a specific data structure that fits you better than sqlite. * Forget about using your program concurrently with others. Future sqlite versions may decide to use different low-level implementations that can clash with your hardcoded functions (this is the same as statically linking the sqlite library with your application). Just my .02 cents... Regards, ~Nuno Lucas
