GNU bug report logs - #77961
31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5

Previous Next

Package: emacs;

Reported by: Iñigo Serna <inigoserna <at> gmx.com>

Date: Mon, 21 Apr 2025 15:58:02 UTC

Severity: normal

Found in version 31.0.50

Fixed in version 31.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Iñigo Serna <inigoserna <at> gmx.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>, 77961 <at> debbugs.gnu.org
Subject: bug#77961: 31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Tue, 22 Apr 2025 10:54:01 +0200
[Message part 1 (text/plain, inline)]
On 22 April 2025 at 10:02 +02, Gerd Möllmann 
<gerd.moellmann <at> gmail.com> wrote:

> Could you please also check with this diff?

This patch solves the problem completely!
I don't know if it's placebo effect but I'd say the rendering is 
even
faster than before.

I attach 2 profiler reports:
- first: with -g3, without native compilation, and without this 
 patch
- second: one with my usual compilation flags, native compilation, 
 and patch applied


Again, thanks a lot for the attention and for solving the problem,
Iñigo Serna

[profiler-g3.txt (text/plain, attachment)]
[profiler-patched.txt (text/plain, attachment)]
[Message part 4 (text/plain, inline)]

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Ihor Radchenko <yantar92 <at> posteo.net> writes:
>>
>>> Iñigo Serna <inigoserna <at> gmx.com> writes:
>>>
>>>> I attach a profiler report of opening the same HTML email 
>>>> with 
>>>> commit
>>>> #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5 reverted (ie, no 
>>>> memset, 
>>>>  no
>>>> for-loop either).
>>>
>>> what could provide more datapoints is compiling with -g3 and 
>>> then
>>> recording perf profile.
>>
>> That and maybe more samples with Emacs' profiler, i.e. run it 
>> say 100
>> times in a loop.
>
> Could you please also check with this diff?
>
> [2. text/x-patch; xxx.diff]...
>
>
> This kind of assumes that set-window-configuration is called in 
> a sort
> of tight loop, and that window matrix sizes actually don't 
> change.

This bug report was last modified 27 days ago.

Previous Next


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