Re: Why is Elisp slow?

[Ergus]

One reason why people implemented everything in elisp instead of
contributing in C (or sending patches) is:

1) in many documents around it says that it is the recommended way to
extend emacs so new users (like me) think that everything is possible
that way.

2) Because emacs didn't have a C api for modules until very recently and
even with that all the infrastructure is Lisp based. (and it still needs
a LOT of documentation) 

3) It was the only available API with documentation and that didn't
require recompile all emacs and they could redistribute, share and
maintain independently without doing all the complex process to
contribute.

Probably (I have a dream) if someone decides to develop a new emacs in
2019 most of the functions and API will be made in pure and clear C (or
any other compiled language), with a full C api that gives the same
access level than what elisp gives in Emacs today (with C lists, arrays
and structs), so it will be not only faster but also simpler to extend
it with other languages like Scheme, Python, Lua, C++, rust and so
on. (There are modules projects going in that direction) And the editor
don't even need to provide a compiler or interpreter for them. (there
will be Guile/gcc/python and so on for that)

But the emacs modules need a lot of time before they can provide the
same power and access than Elisp gives these days, but most of the
infrastructure actually calls indirectly Elisp functions and create Lisp
objects, so there will be not any performance advantage in that part of
the code until it goes back to C or the Lisp->C or the JIT compilers
will be finished.

Vim, for example, added a C api for that reason, but we are talking
about a very different beast here. They don't have their own interpreter
to maintain, no duality with GUI and TUI to maintain, no Lisp objects,
bytecode, debugger... so a very different beast.  



On Thu, May 02, 2019 at 11:20:54PM +0300, Eli Zaretskii wrote:
> > From: ?scar Fuentes <ofv@wanadoo.es>
> > Date: Thu, 02 May 2019 22:12:50 +0200
> >
> > > I have no problem with people who code something for their personal
> > > use.  That's none of my concern.
> >
> > The sceneario I described was about a package maintainer, such as Org.
>
> That was exactly my gripe.  I'm saying that implementing something for
> others should be considered more seriously than just "let's code it
> because we can".
>
> > > As for convincing: that is not required.  Just put the request in the
> > > open, and be done.
> >
> > That's not a solution if you are package maintainer trying to solve a
> > performance problem within a given time frame.
>
> Of course it is: with the Lisp implementation already in place, you
> don't need to wait for anyone or anything.  But requesting a feature
> in addition to that does two things: (a) it alerts others, including
> Emacs developers, to the need; and (b) it announces load and clear
> that the package maintainer is not really happy with the current
> solution.  Without such a request, no one will even know that there's
> a problem here waiting for a volunteer.