[Top][All Lists]

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

Re: Is Elisp really that slow?

From: Stefan Monnier
Subject: Re: Is Elisp really that slow?
Date: Sun, 12 May 2019 17:01:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> I agree that our situation with IDE features is quite bleak, but
>> that's entirely unrelated to the issues discussed in this thread, and
>> its reasons IMO have nothing to do with either ELisp speed or
>> flexibility of Emacs in general.
> It has a lot to do. Analyzing source code is cpu-intensive, because it
> is algorithmically complex and lots of data needs to be processed.

That's part of the problem, but I think it's a minor part of it: most
successful IDEs talk directly to the compiler instead of reimplementing
their own language-implementation-front-end (that requires changes to
the compiler, admittedly, but that's what the `I` is all about).

IOW besides performance, another big challenge is having to
(re)implement a complete language front-end.

I think that's why no effort in this direction took off until LSP:
without LSP, providing IDE-like features in Emacs requires either
hacking your compiler so it gives Emacs the relevant info (this has
been done for a few languages where Emacs users represent a large part
of the population (Lisp and Agda come to mind), but it's rather rare),
or reimplementing a front-end which is hard to justify (and requires
a lot of up-front work before you get any benefit at all).

Most major modes have just enough manpower to get a highlighter and
basic indenter up and running with incremental improvements after that.

Of course, the fact that performance may get in the way makes this even
less attractive.

> Even if you defer the actual analysis to an external tool (which is the
> sane thing to do, BTW)


> the amount of data to be processed on the Emacs end can be quite
> large, more than enough to introduce perceptible delays that spoil
> the experience.

With LSP front-ends using the C-implemented json parser present in recent
Emacsen, this should hopefully be less problematic, but indeed this is
a part where we need to put some of the code in C in order to get good
enough performance.

And the single-threadedness is an additional issue in this respect.


reply via email to

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