Re: Is Elisp really that slow? (was: Why is Elisp slow?)

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Sun, 12 May 2019 18:46:20 +0900
> Cc: help-gnu-emacs@gnu.org
> 
> Well, look at Atom and VS Code which is using the V8 engine (through node) to 
> execute JS to tweak the editor. 
> Now compare that to Emacs.

This is meaningless, unless you describe the use case for comparison
(and while at that, how about some timings instead of hand-waving?).

Most stuff Emacs routinely does is something the other editors could
only dream about, so by and large you are comparing apples to peanuts.

And while I'm here, allow me a few comments regarding this thread's
topic:

 . Speed of ELisp is a valid topic for discussion, but it has very
   little, if anything to do with whether Emacs as a whole is or isn't
   slow.  Why? because speed-critical stuff is not supposed to be
   implemented in Lisp in Emacs, that is not how Emacs is designed and
   implemented.  If you find some operation that is slow in Emacs, it
   just means it might either use more efficient algorithms, or should
   have some of it recoded in C.

 . The speed of various Emacs operations is always a trade-off between
   how fast we want Emacs to be, on the one hand, and how flexible and
   controllable from Lisp we want it to be, OTOH.  When neither better
   algorithms nor reimplementation in C are likely to speed up some
   operation, it means we decided to give up some speed in order to
   have more control and flexibility.  There's nothing wrong with
   that, IMO.

 . Some Emacs operations are slow because no one felt the itch to sit
   down and speed them up -- here's your chance to do something about
   that.