I've thought of that, and to be honest I think it's worth mentioning in the article. But having set this arbitrary limit to 125 lines, before even starting to sketch things down, made me use the function tables. As a plus, article is intended for beginners, and it would be cool if they learn about function pointers from a practical example.

But from a performance perspective, you are right!

Further to this: this kind of thing is something the Forth community takes seriously. They call these threaded code techniques. [0] (The Gforth interpreter, for instance, gives you the choice of various different techniques.)

Anton Ertl of Gforth fame published a microbenchmark performance comparison of toy interpreters, written in C, run on various CPUs. [1] As you say, the approach using function pointers (call threading) scores poorly.

Interestingly, direct threading and indirect threading are extremely close, with the winner seeming to depend on the specific CPU. [1] Branch-prediction differences seem to be the main reason. There was a 2001 paper on this. [2]

[0] https://www.complang.tuwien.ac.at/forth/threaded-code.html

[1] https://www.complang.tuwien.ac.at/forth/threading/

[2] https://github.com/ForthPapersMirror/Papers/blob/master/Conv...

There's also "computed gotos". It's not the same as function pointers, though.

https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e... - article about them being used in CPython

Gforth uses the same trick. https://www.complang.tuwien.ac.at/forth/threaded-code.html