On Sun, Oct 14, 2012 at 7:38 AM, Elefterios Stamatogiannakis < est...@gmail.com> wrote:
> I have some questions for those that know the innards of SQLite. > > What kind of interpreter does the query executor uses? How important is > the interpreter's speed, to SQLite's speed ? > SQLite uses a simple byte-code interpreter implemented as a loop around a big switch statement with a separate case for each opcode. The implementation is in the file vdbe.c. See http://www.sqlite.org/src/artifact/31523df2b986?ln for the latest version of this file. The opcodes in the SQLite byte-code are unlike what you would fine in the VMs for javascript or python. SQLite opcodes are much higher level. In procedural languages, the VM needs to be dominated by opcodes to (for example) add a pair of values together and store the result. SQLite has such opcodes, but they are infrequently used and do not amount to much in terms of performance cost. The bulk of CPU time in the SQLite VM is spent in higher level opcodes such as OP_Insert (which inserts a new entry into a B-Tree) or OP_Column (which decodes the bytes of a row as described at http://www.sqlite.org/fileformat2.html#record_format and return the N-th column of that row). These high-level opcodes are implemented as thousands of lines of highly tuned C code. The overhead of instruction dispatch is insignificant in comparison, according to measurements we have done using cachegrind. > > Concerning above questions, i've found a great article about a portable > interpreter implementation that produces a close to JITed performance, > interpreter: > > http://www.emulators.com/docs/**nx25_nostradamus.htm<http://www.emulators.com/docs/nx25_nostradamus.htm> > > Another idea for producing a portable JIT (without an assembly backend) is > what QEMU does, by "chaining" precompiled functions. Arguably QEMU's way is > more heavy/complex than using an interpreter, but maybe it wouldn't bloat > SQLite that much, and SQLite would remain portable across platforms. > > I'm asking above questions, because i believe that due to SQLite running > on billions of devices it needs to be as efficient as possible. Due to the > number of deployments, it may "burn" GWatts of power across all these > devices (i haven't done the calculation). > > Thanks, > > lefteris. > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
