[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)
Indeed.
> 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.
Stefan
- Re: Is Elisp really that slow?, (continued)
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/16
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/23
- RE: Is Elisp really that slow?, Drew Adams, 2019/05/23
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/23
- Re: Is Elisp really that slow?, Stefan Monnier, 2019/05/16
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/25
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/12
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/12
- Re: Is Elisp really that slow?,
Stefan Monnier <=
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/12
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/13
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/13
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/13
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/14
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/14
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/14
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/14
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/15
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/15