GNU bug report logs - #19776
25.0.50; HTML rendering is very slow

Previous Next

Full log

Message #28 received at 19776 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Richard Stallman <rms <at> gnu.org>, 19776 <at> debbugs.gnu.org
Subject: Re: bug#19776: 25.0.50; HTML rendering is very slow
Date: Fri, 22 Oct 2021 16:59:55 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Richard Stallman <rms <at> gnu.org> writes:
>>
>>> It takes around 5 seconds now -- still enough to lead a user
>>> to think it is broken.  If it is going to take this long,
>>> it should show echo area messages about process.
>>
>> If we had a form like
>>
>> (with-delayed-message (1 "Rendering html...")
>>   ... all the code ...)
>>
>> then we'd be able to display a message if the code took longer than 1
>> second.  We don't have that, do we?
>
> Oh, I asked this before, and the answer is "nope, not at all".
>
> The problem is that it can't be done with normal timers, since "all the
> code" may be pure Elisp and never yield.  For that reason, it can't be
> done with the new thread support, either.
>
> So it would require some C-level magic.

I guess we can't do this for the C-level DEFUN's (without massive
changes), but we might be able to check some timer before executing a
Lisp function or something.  However, wouldn't such a new check risk
slowing Emacs down as a whole?

IOW, I ask if what you ask for is a little bit "too nice", and if we
shouldn't just fix the problematic ELisp code itself to use a progress
reporter or something to that effect.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.