>Each time you ask for the next row of results it has to resume from where it last left off and calculate that next row. The virtual machine is a way of saving state between those calls for the next row (amongst other things).
They could have achieved the same effect by implementing it in a language with continuations or coroutines, or maybe just iterator functions. That might be viable today if the language is fast enough and callable from C.
SQLite predates both; the first official release is from August 2000.
Also, one of the goals of SQLite is to be available everywhere. It's available as super-standard-super-clean C code in one .c file, that works on just about every architecture. Had they used C# or LuaJIT, that could not be achieved.
I'm not sure if you are aware, but SQLite is what powers almost every app on Android or iPhone that needs tabular storage, including the built in ones like Contacts.
"They could have achieved the same effect by implementing it in a language with continuations or coroutines"
They did. They just implemented their own minilanguage instead, that (AFAIK) simply has no conventional syntax-based serialization. It's still a language, though. Given their tight focus, it is completely plausible that they can create a little VM that will run far, far better than any general-purpose language VM could.
But in the end, you're just trading performance for abstractions. There's not really a functional difference between writing the DB in a language running on a VM implemented in C; or writing a DB with a VM implemented in C.
If performance and portability are your goals, C is going to be the logical choice.
Implementing it today would have the same issues: SQLite runs on more platforms than even LuaJIT; and even then I still don't see that a whole general purpose language, no matter how small or embeddable (mostly thinking of Lua here) would compete against SQLite's "be good at SQL-y computation" VM. The main argument for Lua is having humans write it; but the human interface to SQLite is supposed to SQL. I'm not sure I understand the benefit of compiling the SQL down to Lua so it can then be interpreted by the standard Lua implementation...
Comments
>Each time you ask for the next row of results it has to resume from where it last left off and calculate that next row. The virtual machine is a way of saving state between those calls for the next row (amongst other things).
They could have achieved the same effect by implementing it in a language with continuations or coroutines, or maybe just iterator functions. That might be viable today if the language is fast enough and callable from C.
C# and LuaJIT spring to mind.
SQLite predates both; the first official release is from August 2000.
Also, one of the goals of SQLite is to be available everywhere. It's available as super-standard-super-clean C code in one .c file, that works on just about every architecture. Had they used C# or LuaJIT, that could not be achieved.
I'm not sure if you are aware, but SQLite is what powers almost every app on Android or iPhone that needs tabular storage, including the built in ones like Contacts.
"They could have achieved the same effect by implementing it in a language with continuations or coroutines"
They did. They just implemented their own minilanguage instead, that (AFAIK) simply has no conventional syntax-based serialization. It's still a language, though. Given their tight focus, it is completely plausible that they can create a little VM that will run far, far better than any general-purpose language VM could.
But in the end, you're just trading performance for abstractions. There's not really a functional difference between writing the DB in a language running on a VM implemented in C; or writing a DB with a VM implemented in C.
If performance and portability are your goals, C is going to be the logical choice.
You already have the abstractions, they're just C abstractions.
SQLite is used everywhere. Embedded devices, all sorts of different architectures, etc.
C# and LuaJIT are not options. I don't really understand what your point is, because they implemented their own VM instead.
Fair enough, but I was thinking "how would I implement it today" rather than "how should they have implemented it at the time."
Implementing it today would have the same issues: SQLite runs on more platforms than even LuaJIT; and even then I still don't see that a whole general purpose language, no matter how small or embeddable (mostly thinking of Lua here) would compete against SQLite's "be good at SQL-y computation" VM. The main argument for Lua is having humans write it; but the human interface to SQLite is supposed to SQL. I'm not sure I understand the benefit of compiling the SQL down to Lua so it can then be interpreted by the standard Lua implementation...