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

[Samuel Wales]

On 6/8/19, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Fri, Jun 07, 2019 at 05:26:10PM -0700, Samuel Wales wrote:
>> well, for me as a mere user, i just want elisp [per se] to run faster.
>> maybe that has 1000 definitions, but the 3 things that i have read in
>> this thread wfm as PERFECT targets for speeding up and would make
>> emacs even better for me.
>
> Buy a faster computer, then :-)

i was going to add somethning like "without buying a supercomputer"
but figured nobody would say to get a new computer.

an osx help channel was once asked by a disabled person what to do to
increase font sizes for the icons.  these were not configurable at
that time.  therefore their response was that there was nothing wrong
with osx, and the obvious solution was always for the user to get new
glasses.  this included all disabled users of all types.

i suspect that if they were configurable, the answer would have been
that obviously they needed to be configurable.

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.

>>   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.

also, take a look at the profile.  it's kind of flat.  there isn't
anything that obviously takes up the time.

>
>>   2] while re-search-forward do replace-match [iirc] [my question
>> which stefan nicely addressed] to work faster.  this is a tight loop
>> called frequently.
>
> AFAIR the bottleneck here wasn't Elisp at all, but regexp match,
> which is written totally... in C (actually there's a mini-language
> layer in-between). So the totally wrong target for this thread:
> Elisp ain't slow here because it isn't in the equation at all.
>
> Do I remember incorrectly?

i don't know.  i know your feeling.  the thread talks about
keybindings too and i struggle to figure out that relevance.

to me, you remember incorrectly, but i could be wrong.

i thoght th thread was abuot speeding uyp elisp.  improving the c core
or the bytecode or whatever seems to me a perfect speedup.

but i am a mere user.

>
>>   3] elisp to be much faster so that new ideas can be done.
> And this is so generic that it's best served by a generic programming
> language, which Elisp isn't, and for a good reason.

well, what do i know.  i thought perhaps c could be sped up, the core
could replaced with a really optimized lisp, a fwe new elisp
constructs with opimized c like a new re engine could be introduced,
etc.

>
> If you pose a question, you should be ready to expect that the
> answer is... "it depends". That's how learning starts :-)

i think i am regressing.