Re: Why is Elisp slow?

[조성빈]

> 2019. 5. 7. 오전 5:51, Óscar Fuentes <ofv@wanadoo.es> 작성:
> 
> 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.

Does this have a solution to interfacing the Elisp subset translated to C and 
usual Elisp?
It feels like there’s almost no gains compared to using Guile, except that it 
would be marginally faster...

>> 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.

Yeah, and the slow interpreters are what Emacs has in itself.