> What LispE proposes is to turn each instruction of the language into a derived class that exposes an eval method. Every class has its own override of eval. And since all these classes derive from a single mother class with an original and evocative name, Element, you can build a C++ vector that holds them all. And that is where the miracle happens: the AST is kept alive, but each node is an object that can be optimized to the hilt with the full C++ arsenal.
That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, then from the overhead of invoking (virtual) eval() methods, and only then from whatever inefficiencies are inside of those tiny eval() implementations.
If you build flattened a vector of them (as they argue), it can approach a byte code interpreter, though it won't be a very dense vector, if it holds "pointers" (that you need to chase) to the instructions instead of the instructions themselves.
A lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.
That's... a tree-walking interpreter. And IIRC the most overhead of it comes from traversing the tree itself, then from the overhead of invoking (virtual) eval() methods, and only then from whatever inefficiencies are inside of those tiny eval() implementations.
A lot of the slowness of interpreters (and why JITs work) comes from the fact that you're executing (and trying to predict) the interpreter's branches - not the branches in the interpreted code.
This doesn't move the needle there, at all.
[0]: https://github.com/naver
[1]: https://www.naver.com/