Re: Why is Elisp slow?

[Marcin Borkowski]

On 2019-05-02, at 21:45, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Thu, 02 May 2019 21:13:28 +0200
>> 
>> > It's certainly a reason to report this to the Org developers, and ask
>> > them to speed this up.
>> 
>> Well, I don't consider it a bug in Orgmode - rather a bug in my workflow
>
> Maybe improvements in Org could make your bug less prominent...
>
> Then again, it could be that there's some trick up Org developers'
> sleeve that they could teach you.

As it was already said, there's probably not much room for optimization
here - it was raised many times on the Org-mode mailing list.

> In general, anything surprising/inconvenient/buggy should be reported,
> you can never know what will come out of that.
>
>> > (My personal rant to package authors is that they are way too eager to
>> > implement stuff in Lisp which cannot possibly be fast enough or
>> > scalable enough, instead of urging Emacs to provide new C primitives
>> > and core features, or, better, submitting patches to implement such
>> > features in C.  Two cases in point are linum-mode and fci-mode.  End
>> > of rant.)
>> 
>> That is an interesting POV, although I'm not sure if I agree.  IOW,
>> I fully understand why people might do so.  I, for one, consider myself
>> pretty fluent in Elisp and hardly literate in C.
>
> Submitting changes in C is a bonus, it's good enough to describe the
> use case and ask for primitives to support it.  Someone else might get
> motivated.  It could even be very easy, like with fci-mode.
>
> I'm quite sure that some of the bad reputation of Emacs is due to
> incredible things people do in Lisp, which then make Emacs look
> sluggish and bloated.

Possibly.  Still, I guess I never coded something inefficient/big enough
to need the speedup from a potential new C-level feature.  Though I'm
going to remember what you said here, just in case.

Best,

-- 
Marcin Borkowski
http://mbork.pl