help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Is Elisp really that slow?


From: Eli Zaretskii
Subject: Re: Is Elisp really that slow?
Date: Sun, 12 May 2019 21:53:41 +0300

> From: Óscar Fuentes <address@hidden>
> Date: Sun, 12 May 2019 20:37:08 +0200
> 
> When I started with Emacs around 20 years ago, whenever something was
> incorrectly indented or fontified on C++ code I was writing it indicated
> an error on my part. It was way ahead of any other editor. Nowadays CC
> Mode can't handle C++ code styles and constructs that became available
> shortly afterwards the period I mentioned. For languages that became
> popular since the 1990's Emacs is barely adequate on some cases and a
> non-starter on others.
> 
> I'm certainly frustrated because this is a self-inflicted problem.
> Emacs' high-governance (and I mean "really high", you know what I mean)
> forced some very bad decisions upon the project (and not only on Emacs)
> which put us all, developers and users, on a really difficult position.

If you want to explain the problems of CC Mode by some "governance",
you are dead wrong, AFAIK.  The real reasons, IMO, are entirely
different.  At the very least, it was never proven that this has
anything to do with the problems we have.  Anyone who tracks
emacs-devel could easily formulate an alternative hypothesis, which
IMO is much more probable.

In general, problems in Emacs are rarely if ever due to management
(which doesn't really exist), they are almost always due to lack of
manpower, expertise, talent, free time, motivation, etc.

> I have on my to-do list for this year to grab Tromey's JIT branch and
> migrate it to LLVM and see what the optimization passes can squeeze,
> possibly with some simple static analysis and, if I'm in the mood, type
> annotations on Elisp code.

The JIT branch doesn't really work, and I have yet to see any speedup
from it in the configurations where it does compile.  So from my POV,
that experiment is a failure, and (having spent more than one or two
hours on making it work better) I see no reason why the failure could
be fixed by using LLVM, because libjit doesn't use any compiler in the
first place.

So, here too, I see a very weak connection, to say the least, between
your suspected reasons and the reality as I know it.



reply via email to

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