4 ms·

https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00437.html https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00... >To replace an interpreter

by ezoe 8y ago

https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00437.html https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00... >To replace an interpreter by a JIT compiler means more oomplexity and > also more possible problems. (For example, if there are platforms > someday that libjit does not support.) Reading a Lisp interpreter is > very useful for learning. > If the plan is to add a jit and keep the Lisp interpreter as well, > we don't lose its advantages for study, and we can still support all > the platforms -- but we add complexity even more. > I don't think a 3% speedup is worth those drawbacks. Or even a 10% > speedup. A really big speedup would justify the costs. Why do they still let RMS allows to say something about technical today? No wonder Emacs is losing the users.

vkazanov 8y ago
While sometimes overruling he's completely reasonable here. There had been multiple approaches to jit-ing emacs bytecode, and all of them offerred a very limited speed-up. Jitting engines bring extra dependencies and one more layer of complexity to the C core of the editor. And not too many editors support a full language of their own. Notice that Emacs is mostly a volunteer effort and the resources are very limited. For example this particular engine seems to offer a good speed boost on numeric operations but one of the replies mentions that realistic complex code is sometimes slower than a pure byte-code VM. Probably a bug but still... After all those failed attempts certain level of scepticism is understandable.
fantispug 8y ago
A 3% increase in speed is a miniscule improvement. Emacs has a small dedicated group of maintainers, increasing the maintenance burden will stop other developements (such as the recent addition of async which is a much bigger performance issue). If emacs is losing users I would guess it is because to make it an IDE takes more configuration, and has more issues than competing products.
- Latteland 8y ago
  it's 3x, 3 times, not 3%

by ezoe 8y ago

vkazanov 8y ago

While sometimes overruling he's completely reasonable here. There had been multiple approaches to jit-ing emacs bytecode, and all of them offerred a very limited speed-up. Jitting engines bring extra dependencies and one more layer of complexity to the C core of the editor. And not too many editors support a full language of their own. Notice that Emacs is mostly a volunteer effort and the resources are very limited. For example this particular engine seems to offer a good speed boost on numeric operations but one of the replies mentions that realistic complex code is sometimes slower than a pure byte-code VM. Probably a bug but still... After all those failed attempts certain level of scepticism is understandable.

fantispug 8y ago

A 3% increase in speed is a miniscule improvement. Emacs has a small dedicated group of maintainers, increasing the maintenance burden will stop other developements (such as the recent addition of async which is a much bigger performance issue). If emacs is losing users I would guess it is because to make it an IDE takes more configuration, and has more issues than competing products.

Latteland 8y ago
it's 3x, 3 times, not 3%