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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 Iñigo Serna <inigoserna <at> gmx.com>, 77961 <at> debbugs.gnu.org
Subject: Re: bug#77961: 31.0.50; Rendering HTML email is very slow since
 commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Tue, 22 Apr 2025 09:10:42 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>>> I attach a profiler output, and a HTML file which causes a similar
>>>>> slowdown when opening from eww.
>>
>> I'm afraid I don't see much in the profile. Only thing is that that
>> redisplay_internal isn't called often. Which makes it even weirder that
>> glyph matrix enlargement should play a role.
>
> Looking into reverse call tree (B), I see that
>
>         1874  33% + set-window-configuration
>
> takes 1/3 of CPU cycles. Looking into its source, it does deal with
> glyph matrices. So, it is the suspect, judging from the submitted
> profiler report.

Thanks, indeed.

Which I also find weird. Why is that done in the first place? Anyway,
that not leading to redisplays, how can adding a memset or for-loop
settign glyph::frame when adjusting matrices produce a 5x slowdown,
IIUC? I'm absolutely flabbergasted. That all doesn't add up.

Maybe comparing a before/after profile could show something.

Previous Next

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