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

[Eli Zaretskii]

> From: Samuel Wales <samologist@gmail.com>
> Date: Sat, 8 Jun 2019 14:00:23 -0700
> Cc: help-gnu-emacs@gnu.org
> 
> the topic of the thread is elisp speed.  it's true that if a
> significantly faster single-core-throughput computer existed and
> everybody could have access to it, that would solve the problem.  but
> i don't think it is the question that most of us are discussing in
> this particular case.  it definitely is not the quesiton i was
> addressing.

The literal question of whether Lisp can be sped up was answered
already: what we have is probably as fast as it can be.  Minor
improvements are still possible, of course, but they are unlikely to
change the situation drastically, where "drastically" meand something
like 30% at least.  We've hit the wall.

That is why there are "out of the box" ideas that float around, like
JIT byte-compilation, compilation to native code instead of byte code,
etc.  Personally, I'm not sure they will bring a significant speedup,
but since none of those projects was finished yet, I think we should
wait until some of them do before concluding whether any of them show
a direction we should go.

> >>   1] org mode timestamp [aka "daily/weekly"] agenda to complete faster
> >> for a 2 day [...]
> >
> > Dunno about that. Perhaps Org has sub-optimal algorithms there?
> > Why don't you get your hands dirty and profile the whole thing?
> 
> we discussed this on this thread.  it is optimized to death.  it could
> perhaps be rewritten but has not been and that is a large task.  and
> no, i am not capable of it.  and no, that is not the question in this
> particular case.  the question is, can we speed it up, as the topic of
> the thread states, by speeding up elisp.  for example with a faster re
> matcher.

But the re matcher is written in C, and is also optimized to death.
Replacing it with another regexp engine is a huge task, certainly not
smaller than rewriting the Org agenda code, because Emacs has some
unusual requirements from the regexp code (which is why we use a
forked version of an old glibc regexp code, and didn't yet succeed to
migrate to the current glibc code).