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

Previous Next

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: 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: Mon, 21 Apr 2025 22:11:28 +0200

[Message part 1 (text/plain, inline)]

Hi, and thanks for the quick answer.

On 21 April 2025 at 20:31 +02, Gerd Möllmann 
<gerd.moellmann <at> gmail.com> wrote:
> Please try if this helps:
>
> [2. text/x-patch; xxx.diff]...

Sorry, the patch does not solve the issue.

I attach a profiler output, and a HTML file which causes a similar
slowdown when opening from eww.

Thanks,
Iñigo Serna

[profiler.txt (text/plain, attachment)]

[a.html (text/html, attachment)]

[Message part 4 (text/plain, inline)]

On 21 April 2025 at 20:31 +02, Gerd Möllmann 
<gerd.moellmann <at> gmail.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Mon, 21 Apr 2025 10:34:01 +0200
>>> From:  Iñigo Serna via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>> 
>>> Hi,
>>> 
>>> Since a few weeks ago I'm noting that HTML emails rendering is 
>>> very slow,
>>> f.e. from 1 second to 5-6 seconds.
>>> 
>>> I compile Emacs with PGTK and Native Compilation every week on
>>> GNU/Linux Fedora 41/42, and use mu4e to read emails.
>>> More info of my compilation flags below.
>>> 
>>> 
>>> Today I got some free time and proceed to profile the issue, 
>>> it 
>>> showed
>>> ~10x more time in function 'shr-render-td-1' vs emacs v30.1.
>>> 
>>> As this function is not changed since time ago I've bisected 
>>> the 
>>> problem,
>>> which showed that the commit 
>>> #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
>>> was the culprit:
>>> 
>>>    [machine] /h/_/l/d/emacs.bug > git bisect good
>>>        eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5 is the first 
>>>        bad 
>>>        commit
>>>    commit eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
>>>    Author: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>>        Make sure to initialize glyph::frame to NULL 
>>>        (bug#77039)
>>>                * src/dispnew.c (adjust_glyph_matrix): Clear 
>>>                glyph 
>>>                memory when
>>>        enlarging window-system window glyph matrices.
>>>     src/dispnew.c | 3 ++-
>>>     1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> 
>>> If I comment out the two lines added in this commit, problem 
>>> disappears.
>>> 
>>> I've read bug #77039 comment but it's way off my 
>>> understanding.
>>> 
>>> 
>>> But looking deeper into the problem, it is related with my own 
>>> theme,
>>> which hides mode-line of non-active windows by setting its 
>>> height 
>>> to a small value:
>>> 
>>>    (mode-line-inactive ((((type tty)) (:background "#222222" 
>>>    :foreground
>>> ,elms-fg :height 0.1))
>>>                        (((type graphic)) (:background ,elms-bg
>>> :foreground ,elms-fg :height 0.1))))
>>> 
>>> 
>>> If remove that height attribute (or set it to a bigger value 
>>> such 
>>> as 0.6) the issue disappears.
>>
>> Gerd, any comments or suggestions?
>
> Please try if this helps:
>
> [2. text/x-patch; xxx.diff]...
>
>
> The hypothesis behind this would be: The rendering apparently 
> leads to
> increasing glyph matrix sizes; maybe it does something with 
> fonts, no
> idea. The memset clears all glyphs which I can only imagine to 
> play a
> role when we somewhere in the display code compare desired and 
> current
> glyphs, and that fails with the memset and didn't fail without 
> it. Where
> that might be I have no idea.
>
> Anyway, with the loop in my diff it should be as before, and
> glyph::frame is unused in the window-system case, so...

Previous Next

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