Re: Why is Elisp slow?

[Ergus <spacibba@aol.com>]

On Fri, May 03, 2019 at 08:52:06PM +0900, ????????? wrote:
>
>
>The difference between guile and CL is that * Guile is arguably not
>popular and not used by many programs.I???ve never heard a program that
>is popular and uses guile as an extension language. CL is, well, much
>popular than Guile, and is used by industry-strength programs.

> * Guile (which is a scheme) has a radically different syntax with
>elisp (which means that to implement elisp in guile, one has to hack
>the byte code interpreter AFAIK). Elisp can be implemented inside CL
>with full compatibility, which mitigates lots of problems between
>interfacing between CL code and elisp code.

But guile is in fact developed in the gnu project, so there are the
guile developers (very few but they are) that could potentially
provide and fix any issue. But also the strong part of guile is not the
language itself but the potential of the infrastructure.

>* I???m pretty sure CL will be much, much faster than guile.

Probably, that depends of the compiler not only the language.

>CL was optimized for about 30 years or so, and SBCL compiles CL all the way to native code, which is comparable to C. I???m not sure if guile can do that.
>
Guile has been also optimized (in spite of there is a lot of work to do,
that's true) and yes, it can generate native code, but also
bytecode. But it also offers a lot of functionalities to extend and work
as a glue language which is actually most important in our days.

At the end (in my opinion) if emacs wants to survive other 40 years it
will need to start looking for integration with python, lua, C++, rust,
Ruby and similar languages with a more "promising" future than common
lisp. Because we really need to attract new developers with new ideas,
visions and experiences... and 99% of programmers don't use any lisp
like language.

To make big changes we need more developers, that will not come if we
don't have more users first. And those new users/developers can enforce
the new changes looking at the future and not to backward compatibility.


>> https://www.gnu.org/gnu/rms-lisp.en.html <https://www.gnu.org/gnu/rms-lisp.en.html>
>
>I read the link; it???s a pity to not consider CL because it isn???t ???lispy??? enough.
>
>>
>>> IMHO building emacs on CL would be a wonderful idea... and would fix many problems that current Emacs have.
>>>
>> And create others, it is always a trade off.
>
>What problems would CL based Emacs can make????? Can you show some examples????? I am genuinely interested.
>

Dynamic scoping rules vs exical scoping rules in common lisp is just the
first one I can remember, but maybe someone else will reply you with more details.

>>
>> Any way
>>
>> I have to say that comparing to other interpreters around the Elisp is
>> not the slowest one I have tried by far. Of course it could be way
>> faster, but some optimization like user code and provide new containers
>> and datatypes in the library level based in C (and recomend them) code
>> could potentially make more difference in real user extensions.
>
>Well, CL is as fast as C???.
>

But again, common lisp is just a language. Performance is more associated
with the compiler you use. Cython makes python very fast too for
example AND IT IS PYTHON!!!.  The latest version of the GNU common lisp
compiler (GCL) was in 2014... so its developement goes slower than
Guile.

If we had a native compiler for Elisp it could be as fast as common lisp
(ideally). But in any case it needs to be something that goes embedded
within emacs (otherwise emacs won't be emacs anymore).

Think also in the licenses issues and legal consequences of such strong
dependency for a key part of the editor.

On the other hand it is true that in that case that will be a part of
the code that we won't need to maintain if we rely on other packages.

Let me say something. I am not opposed at all to switch to common lisp,
(or scheme or python, actually I think that at some point it will be
needed to change the core language for something more flexible)
what I mean is that this specific problem is not a language issue, but the
compiler. And I don't think that we can just copy the SBCL code into
emacs for many reasons.