Re: Why is Elisp slow?

[Garreau, Alexandre]

On 2018-10-09 at 08:23, Emanuel Berg wrote:
> Garreau, Alexandre wrote:
>
>> elisp is mostly interpreted (contrarily to
>> C which is always compiled to native code, so
>> directly executed by the CPU) and very very
>> dynamic afaik
>
> Why can't Elisp be compiled as well?

Afaik it can, as any turing-complete language, that just requires hard
work: either writing a full native compiler, or interfacing with one
(like gcc).

> With "dynamic", do you mean for example one can change a defun,
> re-eval it, and the next call, still from the same process, will
> execute the new, modified version?
>
> If so, that's a feature we all love and that's why Elisp is so
> addicting because it gives instant feedback. Still, we do it just to a
> tiny tiny fraction of mostly our own Elisp.  The rest stays the same.

For instance.  There are other details such as garbage collection /
dynamic allocation of everything, having everything on heap, dynamic
typing, etc.  But it’s not going to be the most important I guess.

However being able to change anything (or most things) in emacs is a
stated key feature of it, so it makes an full interpreter and the
presence of almost all (elisp) sources mandatory, as well as a fast
(byte-)compiler.

Even more: ideally, to be able to tweak absolutely everything,
everything should be in lisp and nothing in C (or the strict minimal to
make it portable without having to reinvent the wheel of porting to
different architectures in emacs), but afair currently there is still
much in C because indeed elisp is too slow, and the most important
features are needed to be in C so emacs stays usable.

So more work would be needed to give elisp a native compiler… the most
similar approach I recall are gcl (GNU Common Lisp, common lisp is quite
near to elisp) wanting to become a gcc frontend (it’s already compiling
to C), and Guile proposing to become the elisp engine… as guile is
normally faster because more optimizations and stuff, it should have
made elisp faster, but Guile Emacs is actually slow because, afair,
buffer-local variables, dynamic scoping, and low-level stuff like that
are bad supported, and in the end there is really few work on it (and
Guile is far from being as stable as emacs anyway), so as they want to
implement native compilation (but more-or-less (forgot) independently of
gcc afair) too, that’d make a native compiler for elisp… but as the
dynamic stuff is slow on their VM anyway…