[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is Elisp slow?

From: Ergus
Subject: Re: Why is Elisp slow?
Date: Fri, 3 May 2019 15:32:29 +0200
User-agent: NeoMutt/20180716

On Fri, May 03, 2019 at 10:16:32PM +0900, ????????? wrote:
Looks like the point of getting Guile Emacs recurs to:

* How much Guile Emacs is polished(seamless integration with Elisp, full 
compatibility, etc..)
Maybe here is the actual problem.. I actually asked Eli.

* How much Guile supports other languages such as JS or Lua
The C api is pretty nice and easy. I have some code done on it. JS is
a different beast. But having C it is straightforward to interface
python and Lua. Actually the Lua C API is much more complicated that
than Guile's.

* How much Guile manages to be fast

It is decently fine and slowly is getting better.

Guile Emacs was developed for at least 15 years or more, right?

How much can Guile Emacs do these in current situation?????
Is Guile Emacs usable day-to-day?

The problem is maintenance and manpower. The emacs developers are very
busy with bugfixes and there is A LOT of code to maintain/update/fix.

It needs just a voluntary to do the work. I am fine with the C
integration but all Lisp is still a bit esoteric for me.

2019. 5. 3. ?????? 9:51, Ergus <address@hidden> ??????:

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

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 

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]