That should be considerably relevant in this benchmark.

PS you can also run a wider set of benchmarks to compare against stock Emacs using:

https://elpa.gnu.org/packages/elisp-benchmarks.html

Here some not very updated results:

http://akrl.sdf.org/gccemacs.html#org4297f0f

IIUC, you're saying the fib benchmark gets optimized out at speed 3 (and thus run faster than all the implementations discussed here).

But what about speed 2, which is the current default? If we're 15 times slower on this benchmark, does that mean that Node has much cheaper function calls, or something like that?

Because we have to keep Emacs Lisp functions advice-able (which I agree is a good thing)?

Specifically a single fibonacci example is not a good performance indicator by any means.

For instance let's assume V8 is faster in average at running this kind of nanobenchmarks (probably at least for now it is), but how much does it cost to convert non trivial data structures from Lisp to JS and back in a real case?

I expect there will be a lot of back and forward if the system if JS and Lisp get mixed and have to cooperate.

How much does it cost to go through foreign functions calls?

This are just initial thoughts that are not accounted at all here.

And even benchmarking nano-benchmarks can be surprisingly tricky ;) :) https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment...

My questions here are about whether these results indicate further optimization potential for native-comp (in the default configuration, hopefully).

emacs-ng is an interesting experiment, but I think I will only be able to seriously consider it if it comes to reimplementing the Elisp VM on top of V8. Then it will be a single runtime, and little to no data structure conversion and FFI will be required.

In the meantime, I'll keep following the native-comp progress ;), as well as dreaming of Web Workers in stock Elisp API.