Re: Why is Elisp slow?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I totally agree with the sentiment; we'd benefit from "out-sourcing" the
> maintenance of the language implementation, but we can't just replace
> Elisp with something else, so we need to find another well-maintained
> Elisp implementation that's at least as good as that we have now.
>
> AFAIK the options are:
> - Keep what we have
> - Move to Guile
> - Move to CLISP
> - Move to SBCL

- Pick an Elisp subset that can be compiled to efficient machine code
  and has a runtime model that is amenable to C. You retain much of the
  benefits of Elisp but gain fast execution and the possibility of using
  a miriad of libraries. Of course, do not replace Elisp with this, use
  it just when it matters.
  
There are several C-with-a-Lisp-coat implementations out there. I have
one (not public) and know that this method works.

> Another approach would be to implement an Elisp-to-JS compiler and
> then use one of the heavily-optimized JIT-compilers for JS.
> Compiling Elisp to JS should be much easier than compiling to
> native code.

Javascript's JITs seem fast because the interpreters are so slow. Those
JITs only provide near-C code efficiency only on selected cases.
Translating Elisp to JS does not inspire much confidence about the
efficiency of the resulting machine code, not to mention the required
work to interface with current Emacs C base and external libraries.