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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77961 in the body.
You can then email your comments to 77961 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Iñigo Serna <inigoserna <at> gmx.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Rendering HTML email is very slow since commit
 #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Mon, 21 Apr 2025 10:34:01 +0200

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.


Thanks,
-- 
Iñigo Serna


########################################################################






In GNU Emacs 31.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.49, cairo version 1.18.2) of 2025-04-20 built on zeus
Repository revision: 8c04396b198e81c1467314e44b720e3322ca8643
Repository branch: master
System Description: Fedora Linux 42 (Workstation Edition)

Configured using:
'configure -C --prefix=/opt/emacs.git --with-pgtk --with-xinput2
--without-xwidgets --with-native-compilation=aot 
--with-tree-sitter
--disable-gc-mark-trace 'CFLAGS=-O2 -mtune=native -march=native
-fomit-frame-pointer''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ 
JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP 
NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
Important settings:
 value of $LANG: en_US.UTF-8
 locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
 telega-root-auto-fill-mode: t
 telega-contact-birthdays-mode: t
 telega-active-video-chats-mode: t
 telega-active-locations-mode: t
 telega-patrons-mode: t
 telega-notifications-mode: t
 telega-active-stories-mode: t
 global-highlight-changes-mode: t
 highlight-changes-visible-mode: t
 beacon-mode: t
 server-mode: t
 consult-denote-mode: t
 denote-rename-buffer-mode: t
 denote-menu-bar-mode: t
 mu4e-modeline-mode: t
 which-key-mode: t
 pdf-occur-global-minor-mode: t
 nerd-icons-completion-mode: t
 mini-modeline-mode: t
 diff-hl-flydiff-mode: t
 global-diff-hl-mode: t
 global-colorful-mode: t
 colorful-mode: t
 binky-mode: t
 global-atomic-chrome-edit-mode: t
 outline-minor-mode: t
 marginalia-mode: t
 vertico-indexed-mode: t
 vertico-multiform-mode: t
 savehist-mode: t
 vertico-mode: t
 symbol-overlay-mode: t
 flymake-mode: t
 dumb-jump-mode: t
 corfu-popupinfo-mode: t
 corfu-indexed-mode: t
 global-corfu-mode: t
 corfu-mode: t
 electric-pair-mode: t
 recentf-mode: t
 delete-selection-mode: t
 minibuffer-depth-indicate-mode: t
 save-place-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 eldoc-mode: t
 show-paren-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 tab-bar-mode: t
 file-name-shadow-mode: t
 context-menu-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 minibuffer-regexp-mode: t
 size-indication-mode: t
 column-number-mode: t
 line-number-mode: t
 transient-mark-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t
 abbrev-mode: t
 hs-minor-mode: t

Load-path shadows:
None found.

Features:
(shadow shr-color sort gnus-cite mm-archive mail-extr qp textsec
uni-scripts idna-mapping ucs-normalize uni-confusable 
textsec-check
em-unix em-term em-script em-prompt em-pred em-ls em-hist em-glob
em-extpipe em-cmpl em-dirs em-basic em-banner em-alias esh-mode 
esh-var
telega-obsolete telega telega-tdlib-events telega-match 
telega-root
telega-info telega-chat telega-modes telega-company telega-emoji
telega-user telega-notifications telega-voip telega-msg 
telega-story
telega-webpage visual-fill-column telega-tme telega-sticker
telega-vvnote telega-ffplay telega-i18n telega-sort telega-filter
telega-ins telega-inline telega-util telega-folders telega-topic
telega-media telega-tdlib telega-server telega-core cursor-sensor
telega-customize emacsbug display-line-numbers network-stream 
url-http
url-gw nsm url-cache url-auth help-fns radix-tree vertico-sort 
orderless
org-indent oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus
nnselect ol-docview doc-view ol-bibtex bibtex ol-bbdb ol-w3m 
ol-doi
org-link-doi go-mode find-file etags fileloop calc calc-loaddefs
calc-macs denote-journal hilit-chg beacon server tramp-adb 
tramp-cache
time-stamp tramp-sh checkdoc lisp-mnt vterm vterm-module 
term/xterm
xterm flyspell ispell transient consult-denote denote calfw-org
org-capture org-agenda calfw-ical icalendar diary-lib 
diary-loaddefs
calfw-cal calfw edmacro holidays holiday-loaddefs org-contacts cl
ob-python ob-shell org-superstar org-protocol timezone 
mu4e-contrib mu4e
mu4e-org mu4e-notification mu4e-main smtpmail mu4e-view 
mu4e-mime-parts
crm mu4e-headers mu4e-thread mu4e-actions mu4e-compose mu4e-draft
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud 
nnimap
nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range 
gnus-win
mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message 
flow-fill
mu4e-contacts mu4e-update mu4e-folders mu4e-context 
mu4e-query-items
mu4e-server mu4e-modeline mu4e-vars mu4e-helpers mu4e-config 
mu4e-window
mu4e-obsolete which-key printing ps-print ps-print-loaddefs lpr
per-buffer-theme pdf-occur ibuf-ext ibuffer ibuffer-loaddefs 
tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
pdf-misc pdf-tools pdf-view jka-compr pdf-cache pdf-info tq 
pdf-util
pdf-macs image-mode exif notifications dbus nerd-icons-completion
nerd-icons-dired nerd-icons nerd-icons-faces nerd-icons-data
nerd-icons-data-mdicon nerd-icons-data-flicon 
nerd-icons-data-codicon
nerd-icons-data-devicon nerd-icons-data-sucicon 
nerd-icons-data-wicon
nerd-icons-data-faicon nerd-icons-data-powerline 
nerd-icons-data-octicon
nerd-icons-data-pomicon nerd-icons-data-ipsicon mynewspaper
multiple-cursors mc-separate-operations rectangular-region-mode
mc-mark-pop mc-edit-lines minimap mini-modeline face-remap lms 
iedit
iedit-lib mc-hide-unmatched-lines-mode mc-mark-more 
html-mode-expansions
sgml-mode mc-cycle-cursors multiple-cursors-core rect 
hideshow-fringe
hideshow gptel-openai-extras gptel-ollama gptel gptel-openai
google-translate-smooth-ui google-translate 
google-translate-default-ui
google-translate-core-ui facemenu ido google-translate-core
google-translate-backend expand-region text-mode-expansions
the-org-mode-expansions python-el-fgallina-expansions
er-basic-expansions expand-region-core expand-region-custom
diff-hl-flydiff diff-hl log-view log-edit message sendmail 
yank-media
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse 
rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader add-log
pcvs-util vc-dir vc vc-dispatcher epa-file epa epg rfc6068 
epg-config
colorful-mode binky-mode avy atomic-chrome websocket bindat 
let-alist
webkit-ace webkit webkit-module derived eww vtable mule-util 
url-queue
shr pixel-fill kinsoku url-file puny mm-url gnus nnheader 
gnus-util
mail-utils range mm-util mail-prsvr embark-org org-element 
org-persist
org-id org-refile org-element-ast inline avl-tree org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie
executable ob-comint org-pcomplete org-list org-footnote org-faces
org-entities noutline outline ob-emacs-lisp ob-core ob-eval 
org-cycle
org-table ol org-fold org-fold-core org-keys oc org-loaddefs 
cal-menu
calendar cal-loaddefs org-version org-compat org-macs shell-pop 
term
disp-table ehelp em-tramp tramp trampver tramp-integration 
tramp-message
tramp-compat shell parse-time iso8601 time-date format-spec
tramp-loaddefs eshell esh-cmd generator esh-ext esh-proc esh-opt 
esh-io
esh-arg pcomplete esh-module esh-module-loaddefs esh-util files-x
dired-subtree dired-narrow dired-hacks-utils dired-aux dired-x 
dired
dired-loaddefs embark-consult embark ffap marginalia consult-dir 
consult
bookmark vertico-indexed vertico-multiform savehist vertico
symbol-overlay eglot external-completion jsonrpc flymake thingatpt 
diff
diff-mode track-changes ert ewoc debug backtrace find-func 
filenotify
compile text-property-search imenu dumb-jump popup dash s xref 
cape
kind-icon svg-lib color svg xml corfu-popupinfo corfu-indexed 
corfu
cus-edit pp cus-load python project compat treesit comint ansi-osc 
ring
ansi-color dom pcase kmacro advice inigo-theme easy-mmode hl-line
elec-pair recentf tree-widget wid-edit reveal delsel mb-depth comp
comp-cstr comp-run comp-common rx saveplace finder-inf info
atomic-chrome-autoloads avy-autoloads beacon-autoloads
binky-mode-autoloads calfw-cal-autoloads calfw-ical-autoloads
calfw-org-autoloads cape-autoloads colorful-mode-autoloads
consult-denote-autoloads consult-dir-autoloads corfu-autoloads
debbugs-autoloads denote-journal-autoloads 
denote-markdown-autoloads
denote-org-autoloads denote-silo-autoloads denote-autoloads
diff-hl-autoloads dired-narrow-autoloads dired-subtree-autoloads
dired-hacks-utils-autoloads dumb-jump-autoloads 
embark-consult-autoloads
consult-autoloads embark-autoloads expand-region-autoloads
expreg-autoloads focus-autoloads go-mode-autoloads
google-translate-autoloads gptel-autoloads helpful-autoloads
elisp-refs-autoloads f-autoloads htmlize-autoloads jinx-autoloads
kind-icon-autoloads ledger-mode-autoloads marginalia-autoloads
markdown-mode-autoloads mastodon-autoloads mini-modeline-autoloads
multiple-cursors-autoloads nerd-icons-completion-autoloads
nerd-icons-dired-autoloads nerd-icons-autoloads nov-autoloads
esxml-autoloads orderless-autoloads org-superstar-autoloads
pdf-tools-autoloads per-buffer-theme-autoloads persist-autoloads
popup-autoloads posframe-autoloads request-autoloads 
shell-pop-autoloads
svg-lib-autoloads symbol-overlay-autoloads tablist-autoloads
telega-autoloads tp-autoloads ts-autoloads s-autoloads 
dash-autoloads
vertico-autoloads visual-fill-column-autoloads vterm-autoloads
web-mode-autoloads websocket-autoloads wgrep-autoloads
yaml-mode-autoloads yasnippet-autoloads package browse-url xdg url
url-proxy url-privacy url-expand url-methods url-history 
url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers 
url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json 
subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-extra help-mode
warnings icons cl-loaddefs cl-lib rmc iso-transl tooltip cconv 
eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type 
elisp-mode
mwheel term/pgtk-win pgtk-win term/common-win touch-screen 
pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list 
replace
newcomment text-mode lisp-mode prog-mode register page tab-bar 
menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse 
jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer 
nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese 
eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic 
indian
cyrillic chinese composite emoji-zwj charscript charprop 
case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded 
button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads 
dbusbind
inotify dynamic-setting system-font-setting font-render-setting 
cairo
gtk pgtk lcms2 multi-tty move-toolbar make-network-process
tty-child-frames native-compile emacs)

Memory information:
((conses 16 1478725 958791) (symbols 48 63790 373) (strings 32 
356656 45848)
(string-bytes 1 10452743) (vectors 16 146706) (vector-slots 8 
2469732 617832)
(floats 8 1987 12487) (intervals 56 30939 9636) (buffers 992 29))

-- 
Iñigo Serna

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Iñigo Serna <inigoserna <at> gmx.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 77961 <at> debbugs.gnu.org
Subject: Re: bug#77961: 31.0.50; Rendering HTML email is very slow since commit
 #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Mon, 21 Apr 2025 21:07:21 +0300

> 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?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Mon, 21 Apr 2025 20:31:53 +0200

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

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:

[xxx.diff (text/x-patch, attachment)]

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

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...

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 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: Mon, 21 Apr 2025 20:46:07 +0200

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

> Anyway, with the loop in my diff it should be as before, and
> glyph::frame is unused in the window-system case, so...

And maybe one other thing: I wonder how this can have the said
performance effect in the first place. Does this renderer call redisplay
over and over, or what is happening there?

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

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: Re: 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...

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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 06:35:39 +0200

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

> 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.

Then I'm out of ideas for the moment.

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

Thanks. Can you please tell how I can make this happen using the HTML
file? I'm not familiar with this part of Emacs.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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 06:39:47 +0200

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

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

Can you please tell what the profiler output is? Looks like Lisp data in
one text line?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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 06:43:12 +0200

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

> Iñigo Serna <inigoserna <at> gmx.com> writes:
>
>> I attach a profiler output, and a HTML file which causes a similar
>> slowdown when opening from eww.
>
> Can you please tell what the profiler output is? Looks like Lisp data in
> one text line?

Please forget that, profiler-find.* etc.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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 07:24:53 +0200

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

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Iñigo Serna <inigoserna <at> gmx.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.

Do we have someone available who knows how shr.el works internally, Eli?

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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 06:30:36 +0000

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.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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.

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

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: Re: bug#77961: 31.0.50; Rendering HTML email is very slow since
 commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Tue, 22 Apr 2025 09:28:38 +0200

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

Hi,

On 22 April 2025 at 09:10 +02, Gerd Möllmann 
<gerd.moellmann <at> gmail.com> wrote:

> Maybe comparing a before/after profile could show something.

I attach a profiler report of opening the same HTML email with 
commit
#eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5 reverted (ie, no memset, 
no
for-loop either).

I attached an HTML sample file in a past message.
Opening it inside eww produces a similar slowdown on my system, 
maybe a
bit shorter (~3-4 sec).  Without memset or for-loop is almost
instantaneous.


Thanks,
Iñigo Serna

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

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

> 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.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 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 07:31:47 +0000

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.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #44 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:41:56 +0200

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.

Message #47 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 10:02:58 +0200

[Message part 1 (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?

[xxx.diff (text/x-patch, attachment)]

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

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.

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

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: Re: 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.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 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 08:58:03 +0000

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

> I attach 2 profiler reports:
> - first: with -g3, without native compilation, and without this 
>   patch

I think there was a confusion. I did not mean M-x profiler report for
-g3, but GNU perf's profile:
perf record -p <emacs pid>
...
C-c
perf report

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 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 11:29:35 +0200

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

> 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.

No placebo. The code is this:

dispnew.c:
  496       if (dim.width > matrix->matrix_w

Translate into plain English: If the matrix width has changed, or

  497           || new_rows

the height has changed, 

  498           || tab_line_changed_p
  499           || header_line_changed_p
  500           || marginal_areas_changed_p)

or some other stuff has changed.

  501         {
  502           struct glyph_row *row = matrix->rows;
  503           struct glyph_row *end = row + matrix->rows_allocated;
  504
  505           while (row < end)
  506             {

  For all rows of the matrix

  507               if (dim.width > matrix->matrix_w || new_rows)
  508                 {
  509                   row->glyphs[LEFT_MARGIN_AREA]
  510                     = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
  511                                  dim.width, sizeof (struct glyph));
  512                   /* We actually need to clear only the 'frame' member, but
  513                      it's easier to clear everything.  */
  514                   memset (row->glyphs[LEFT_MARGIN_AREA], 0,
  515                           dim.width * sizeof (struct glyph));

Realloc and memset

  516                 }
  517 

Realloc and msmset are only necessary when the matrix was made larger.
Under some conditions in the if above this is not the case. And it got
faster than before because avoid the realloc too when the matrix
dimensions were actually not enlarged.

Everything not a problem, unless someone triggers matrix adjustments
really really frequently. And that's what apparently happens somewhere
in this rendering thing.

(Might be considered a performance bug in shr-, but I don't know if
there's maybe a reason for that. Might be worth reporting, but anyway, I
don't want be dragged into that :-).)

>
> 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

Thanks for the report and for testing it!

I'll push something soon.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 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 11:41:07 +0200

Pushed and closing.

Thanks to Ihor for spotting the culprit!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, martin
 rudalics <rudalics <at> gmx.at>
Cc: yantar92 <at> posteo.net, 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 15:55:18 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Iñigo Serna <inigoserna <at> gmx.com>,  Eli Zaretskii
>  <eliz <at> gnu.org>,
>   77961 <at> debbugs.gnu.org
> 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?

If the comment in set-window-configuration before it messes with glyph
matrices doesn't answer this question, maybe Martin (CC'ed) can help us
understand the reason?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, yantar92 <at> posteo.net, 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 14:57:51 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Iñigo Serna <inigoserna <at> gmx.com>,  Eli Zaretskii
>>  <eliz <at> gnu.org>,
>>   77961 <at> debbugs.gnu.org
>> 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?
>
> If the comment in set-window-configuration before it messes with glyph
> matrices doesn't answer this question, maybe Martin (CC'ed) can help us
> understand the reason?

Thanks, but I meant why does shr so many set-window-configuration calls.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: yantar92 <at> posteo.net, 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 15:57:58 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Iñigo Serna <inigoserna <at> gmx.com>,  Eli Zaretskii
>  <eliz <at> gnu.org>,
>   77961 <at> debbugs.gnu.org
> Date: Tue, 22 Apr 2025 10:02:58 +0200
> 
> Could you please also check with this diff?
> 
> diff --git a/src/dispnew.c b/src/dispnew.c
> index 24bf975ef9f..40df078aea6 100644
> --- a/src/dispnew.c
> +++ b/src/dispnew.c
> @@ -504,13 +504,16 @@ adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y
>  
>  	  while (row < end)
>  	    {
> -	      row->glyphs[LEFT_MARGIN_AREA]
> -		= xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
> -			     dim.width, sizeof (struct glyph));
> -	      /* We actually need to clear only the 'frame' member, but
> -                 it's easier to clear everything.  */
> -	      memset (row->glyphs[LEFT_MARGIN_AREA], 0,
> -		      dim.width * sizeof (struct glyph));
> +	      if (dim.width > matrix->matrix_w || new_rows)
> +		{
> +		  row->glyphs[LEFT_MARGIN_AREA]
> +		    = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
> +				 dim.width, sizeof (struct glyph));
> +		  /* We actually need to clear only the 'frame' member, but
> +		     it's easier to clear everything.  */
> +		  memset (row->glyphs[LEFT_MARGIN_AREA], 0,
> +			  dim.width * sizeof (struct glyph));
> +		}

This means a very large matrix will not be downsized when possible.
Is that a good idea?  Maybe try replacing '>' with '!=' and see if it
also solves the problem?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 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 15:04:59 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Iñigo Serna <inigoserna <at> gmx.com>,  Eli Zaretskii
>>  <eliz <at> gnu.org>,
>>   77961 <at> debbugs.gnu.org
>> Date: Tue, 22 Apr 2025 10:02:58 +0200
>> 
>> Could you please also check with this diff?
>> 
>> diff --git a/src/dispnew.c b/src/dispnew.c
>> index 24bf975ef9f..40df078aea6 100644
>> --- a/src/dispnew.c
>> +++ b/src/dispnew.c
>> @@ -504,13 +504,16 @@ adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y
>>  
>>  	  while (row < end)
>>  	    {
>> -	      row->glyphs[LEFT_MARGIN_AREA]
>> -		= xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
>> -			     dim.width, sizeof (struct glyph));
>> -	      /* We actually need to clear only the 'frame' member, but
>> -                 it's easier to clear everything.  */
>> -	      memset (row->glyphs[LEFT_MARGIN_AREA], 0,
>> -		      dim.width * sizeof (struct glyph));
>> +	      if (dim.width > matrix->matrix_w || new_rows)
>> +		{
>> +		  row->glyphs[LEFT_MARGIN_AREA]
>> +		    = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
>> +				 dim.width, sizeof (struct glyph));
>> +		  /* We actually need to clear only the 'frame' member, but
>> +		     it's easier to clear everything.  */
>> +		  memset (row->glyphs[LEFT_MARGIN_AREA], 0,
>> +			  dim.width * sizeof (struct glyph));
>> +		}
>
> This means a very large matrix will not be downsized when possible.
> Is that a good idea?  Maybe try replacing '>' with '!=' and see if it
> also solves the problem?

It's at least what I originally intended when I wrote that function. On
the grounds that if it grew to some size once, it woiuld likely again to
that size again. Compare the allocation of the row vector where I did
the same, for the same reason.

dispnew.c:
  416   /* Enlarge MATRIX->rows if necessary.  New rows are cleared.  */
  417   if (matrix->rows_allocated < dim.height)
  418     {
  419       int old_alloc = matrix->rows_allocated;
  420       new_rows = dim.height - matrix->rows_allocated;
  421       matrix->rows = xpalloc (matrix->rows, &matrix->rows_allocated,
  422                               new_rows, INT_MAX, sizeof *matrix->rows);
  423       memset (matrix->rows + old_alloc, 0,
  424               (matrix->rows_allocated - old_alloc)
  425                 * sizeof *matrix->rows);
  426     }
  427   else
  428     new_rows = 0;

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, yantar92 <at> posteo.net, 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 16:13:37 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: martin rudalics <rudalics <at> gmx.at>,  yantar92 <at> posteo.net,
>   inigoserna <at> gmx.com,  77961 <at> debbugs.gnu.org
> Date: Tue, 22 Apr 2025 14:57:51 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > 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?
> >
> > If the comment in set-window-configuration before it messes with glyph
> > matrices doesn't answer this question, maybe Martin (CC'ed) can help us
> > understand the reason?
> 
> Thanks, but I meant why does shr so many set-window-configuration calls.

It calls save-window-excursion.  It does that because it performs
layout in Lisp, so it needs to futz with the selected window's
settings.

I believe if you set shr-use-fonts to nil, this will be avoided.  (But
the layout will be less pretty when using variable-pitch fonts.)

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, yantar92 <at> posteo.net, 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 15:18:50 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: martin rudalics <rudalics <at> gmx.at>,  yantar92 <at> posteo.net,
>>   inigoserna <at> gmx.com,  77961 <at> debbugs.gnu.org
>> Date: Tue, 22 Apr 2025 14:57:51 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> > 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?
>> >
>> > If the comment in set-window-configuration before it messes with glyph
>> > matrices doesn't answer this question, maybe Martin (CC'ed) can help us
>> > understand the reason?
>> 
>> Thanks, but I meant why does shr so many set-window-configuration calls.
>
> It calls save-window-excursion.  It does that because it performs
> layout in Lisp, so it needs to futz with the selected window's
> settings.
>
> I believe if you set shr-use-fonts to nil, this will be avoided.  (But
> the layout will be less pretty when using variable-pitch fonts.)

Thanks.

I'm wondering if shr could do its thing within one save-window-excursion,
or at least in fewer of them? But that's something for some shr specialist.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: yantar92 <at> posteo.net, 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 16:19:01 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: yantar92 <at> posteo.net,  inigoserna <at> gmx.com,  77961 <at> debbugs.gnu.org
> Date: Tue, 22 Apr 2025 15:04:59 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> +	      if (dim.width > matrix->matrix_w || new_rows)
> >> +		{
> >> +		  row->glyphs[LEFT_MARGIN_AREA]
> >> +		    = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
> >> +				 dim.width, sizeof (struct glyph));
> >> +		  /* We actually need to clear only the 'frame' member, but
> >> +		     it's easier to clear everything.  */
> >> +		  memset (row->glyphs[LEFT_MARGIN_AREA], 0,
> >> +			  dim.width * sizeof (struct glyph));
> >> +		}
> >
> > This means a very large matrix will not be downsized when possible.
> > Is that a good idea?  Maybe try replacing '>' with '!=' and see if it
> > also solves the problem?
> 
> It's at least what I originally intended when I wrote that function. On
> the grounds that if it grew to some size once, it woiuld likely again to
> that size again. Compare the allocation of the row vector where I did
> the same, for the same reason.
> 
> dispnew.c:
>   416   /* Enlarge MATRIX->rows if necessary.  New rows are cleared.  */
>   417   if (matrix->rows_allocated < dim.height)
>   418     {
>   419       int old_alloc = matrix->rows_allocated;
>   420       new_rows = dim.height - matrix->rows_allocated;
>   421       matrix->rows = xpalloc (matrix->rows, &matrix->rows_allocated,
>   422                               new_rows, INT_MAX, sizeof *matrix->rows);
>   423       memset (matrix->rows + old_alloc, 0,
>   424               (matrix->rows_allocated - old_alloc)
>   425                 * sizeof *matrix->rows);
>   426     }
>   427   else
>   428     new_rows = 0;

So if the user drags the right side of the frame to make it very wide,
or just toggles it full-screen, we will grow the glyph matrices and
never free that space, ever, for as long as the Emacs session lives?
With today's large screens that could be a significant waste of memory
that is never returned to the system, I think?

If the problem we want to avoid is reallocating when the size doesn't
change (which was what happened in this case), then just '!=' should
prevent it, while simultaneously letting us free some memory when the
window is down-sized.  Whether such a realloc actually frees memory is
up to the implementation, but why not let it do what it supposedly
does best?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 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 15:28:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: yantar92 <at> posteo.net,  inigoserna <at> gmx.com,  77961 <at> debbugs.gnu.org
>> Date: Tue, 22 Apr 2025 15:04:59 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> +	      if (dim.width > matrix->matrix_w || new_rows)
>> >> +		{
>> >> +		  row->glyphs[LEFT_MARGIN_AREA]
>> >> +		    = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
>> >> +				 dim.width, sizeof (struct glyph));
>> >> +		  /* We actually need to clear only the 'frame' member, but
>> >> +		     it's easier to clear everything.  */
>> >> +		  memset (row->glyphs[LEFT_MARGIN_AREA], 0,
>> >> +			  dim.width * sizeof (struct glyph));
>> >> +		}
>> >
>> > This means a very large matrix will not be downsized when possible.
>> > Is that a good idea?  Maybe try replacing '>' with '!=' and see if it
>> > also solves the problem?
>> 
>> It's at least what I originally intended when I wrote that function. On
>> the grounds that if it grew to some size once, it woiuld likely again to
>> that size again. Compare the allocation of the row vector where I did
>> the same, for the same reason.
>> 
>> dispnew.c:
>>   416   /* Enlarge MATRIX->rows if necessary.  New rows are cleared.  */
>>   417   if (matrix->rows_allocated < dim.height)
>>   418     {
>>   419       int old_alloc = matrix->rows_allocated;
>>   420       new_rows = dim.height - matrix->rows_allocated;
>>   421       matrix->rows = xpalloc (matrix->rows, &matrix->rows_allocated,
>>   422                               new_rows, INT_MAX, sizeof *matrix->rows);
>>   423       memset (matrix->rows + old_alloc, 0,
>>   424               (matrix->rows_allocated - old_alloc)
>>   425                 * sizeof *matrix->rows);
>>   426     }
>>   427   else
>>   428     new_rows = 0;
>
> So if the user drags the right side of the frame to make it very wide,
> or just toggles it full-screen, we will grow the glyph matrices and
> never free that space, ever, for as long as the Emacs session lives?
> With today's large screens that could be a significant waste of memory
> that is never returned to the system, I think?
>
> If the problem we want to avoid is reallocating when the size doesn't
> change (which was what happened in this case), then just '!=' should
> prevent it, while simultaneously letting us free some memory when the
> window is down-sized.  Whether such a realloc actually frees memory is
> up to the implementation, but why not let it do what it supposedly
> does best?

It has always been in done in something like the if below. Note the
first two conditions. There have never been re-allocations to shrink a
matrix. 

dispnew.c:
  493       /* If MATRIX->pool is null, MATRIX is responsible for managing
  494          its own memory.  It is a window matrix for window-based redisplay.
  495          Allocate glyph memory from the heap.  */
  496       if (dim.width > matrix->matrix_w
  497           || new_rows
  498           || tab_line_changed_p
  499           || header_line_changed_p
  500           || marginal_areas_changed_p)
  501         {

So shrinking is a new idea. One could try that out, but it's not
something for me ATM, sorry.

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

From: Iñigo Serna <inigoserna <at> gmx.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, yantar92 <at> posteo.net, 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 15:40:32 +0200

I confirm that replacing '>' with '!=' solves the problem as well.

On 22 April 2025 at 15:28 +02, Gerd Möllmann 
<gerd.moellmann <at> gmail.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>> Cc: yantar92 <at> posteo.net,  inigoserna <at> gmx.com, 
>>> 77961 <at> debbugs.gnu.org
>>> Date: Tue, 22 Apr 2025 15:04:59 +0200
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> >> +	      if (dim.width > matrix->matrix_w || new_rows)
>>> >> +		{
>>> >> +		  row->glyphs[LEFT_MARGIN_AREA]
>>> >> +		    = xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
>>> >> +				 dim.width, sizeof (struct glyph));
>>> >> +		  /* We actually need to clear only the 'frame' 
>>> >> member, but
>>> >> +		     it's easier to clear everything.  */
>>> >> +		  memset (row->glyphs[LEFT_MARGIN_AREA], 0,
>>> >> +			  dim.width * sizeof (struct glyph));
>>> >> +		}
>>> >
>>> > This means a very large matrix will not be downsized when 
>>> > possible.
>>> > Is that a good idea?  Maybe try replacing '>' with '!=' and 
>>> > see if it
>>> > also solves the problem?
>>> 
>>> It's at least what I originally intended when I wrote that 
>>> function. On
>>> the grounds that if it grew to some size once, it woiuld 
>>> likely again to
>>> that size again. Compare the allocation of the row vector 
>>> where I did
>>> the same, for the same reason.
>>> 
>>> dispnew.c:
>>>   416   /* Enlarge MATRIX->rows if necessary.  New rows are 
>>>   cleared.  */
>>>   417   if (matrix->rows_allocated < dim.height)
>>>   418     {
>>>   419       int old_alloc = matrix->rows_allocated;
>>>   420       new_rows = dim.height - matrix->rows_allocated;
>>>   421       matrix->rows = xpalloc (matrix->rows, 
>>>   &matrix->rows_allocated,
>>>   422                               new_rows, INT_MAX, sizeof 
>>>   *matrix->rows);
>>>   423       memset (matrix->rows + old_alloc, 0,
>>>   424               (matrix->rows_allocated - old_alloc)
>>>   425                 * sizeof *matrix->rows);
>>>   426     }
>>>   427   else
>>>   428     new_rows = 0;
>>
>> So if the user drags the right side of the frame to make it 
>> very wide,
>> or just toggles it full-screen, we will grow the glyph matrices 
>> and
>> never free that space, ever, for as long as the Emacs session 
>> lives?
>> With today's large screens that could be a significant waste of 
>> memory
>> that is never returned to the system, I think?
>>
>> If the problem we want to avoid is reallocating when the size 
>> doesn't
>> change (which was what happened in this case), then just '!=' 
>> should
>> prevent it, while simultaneously letting us free some memory 
>> when the
>> window is down-sized.  Whether such a realloc actually frees 
>> memory is
>> up to the implementation, but why not let it do what it 
>> supposedly
>> does best?
>
> It has always been in done in something like the if below. Note 
> the
> first two conditions. There have never been re-allocations to 
> shrink a
> matrix. 
>
> dispnew.c:
>   493       /* If MATRIX->pool is null, MATRIX is responsible 
>   for managing
>   494          its own memory.  It is a window matrix for 
>   window-based redisplay.
>   495          Allocate glyph memory from the heap.  */
>   496       if (dim.width > matrix->matrix_w
>   497           || new_rows
>   498           || tab_line_changed_p
>   499           || header_line_changed_p
>   500           || marginal_areas_changed_p)
>   501         {
>
> So shrinking is a new idea. One could try that out, but it's not
> something for me ATM, sorry.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Iñigo Serna <inigoserna <at> gmx.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, yantar92 <at> posteo.net, 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 15:50:00 +0200

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

> I confirm that replacing '>' with '!=' solves the problem as well.

Okay, thanks, but I'd prefer a design for shrinking matrices over one
more ad-hoc decision. YYMV.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann
 <gerd.moellmann <at> gmail.com>
Cc: yantar92 <at> posteo.net, 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: Wed, 23 Apr 2025 08:17:29 +0200

>>> 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?
>
> If the comment in set-window-configuration before it messes with glyph
> matrices doesn't answer this question, maybe Martin (CC'ed) can help us
> understand the reason?

Do you mean the adjust_frame_glyphs call?  It's called whenever we may
have changed window sizes.  We could have 'set-window-configuration' use
checks similar to those from run_window_change_functions.  But such a
change would have to be done with considerable care: After all, an
accidentally missing call of 'window-size-change-functions' would be
hardly noticed.  The missing update of a glyph matrix would be much more
harmful.

'save-window-excursion' should be banned.  Its reminder

  BEWARE: Most uses of this macro introduce bugs.

is much too mild in my opinion.  AFAICT the first two calls in shr.el
could be avoided by using 'buffer-text-pixel-size'.  The one in
'shr-render-td-1' looks worse - since it calls 'shr-pixel-buffer-width'
it nests one 'save-window-excursion' call into another which is simply
evil.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: gerd.moellmann <at> gmail.com, yantar92 <at> posteo.net, 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: Wed, 23 Apr 2025 16:21:34 +0300

> Date: Wed, 23 Apr 2025 08:17:29 +0200
> Cc: yantar92 <at> posteo.net, inigoserna <at> gmx.com, 77961 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
> 'save-window-excursion' should be banned.  Its reminder
> 
>    BEWARE: Most uses of this macro introduce bugs.
> 
> is much too mild in my opinion.  AFAICT the first two calls in shr.el
> could be avoided by using 'buffer-text-pixel-size'.  The one in
> 'shr-render-td-1' looks worse - since it calls 'shr-pixel-buffer-width'
> it nests one 'save-window-excursion' call into another which is simply
> evil.

Thanks.  Patches welcome to avoid using save-window-excursion in
shr.el.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, martin rudalics <rudalics <at> gmx.at>,
 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: Wed, 23 Apr 2025 15:44:03 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>>    BEWARE: Most uses of this macro introduce bugs.
>> 
>> is much too mild in my opinion.  AFAICT the first two calls in shr.el
>> could be avoided by using 'buffer-text-pixel-size'.  The one in
>> 'shr-render-td-1' looks worse - since it calls 'shr-pixel-buffer-width'
>> it nests one 'save-window-excursion' call into another which is simply
>> evil.
>
> Thanks.  Patches welcome to avoid using save-window-excursion in
> shr.el.

It is difficult until there is a clear picture why

(save-window-excursion
          ;; Avoid errors if the selected window is a dedicated one,
          ;; and they just want to insert a document into it.
          (set-window-dedicated-p nil nil)
	  (set-window-buffer nil (current-buffer))
	  (car (window-text-pixel-size nil (line-beginning-position) (point))))

dance is even necessary.
For example, `string-pixel-width' somehow does not need it.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: gerd.moellmann <at> gmail.com, rudalics <at> gmx.at, 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: Thu, 24 Apr 2025 08:13:25 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: martin rudalics <rudalics <at> gmx.at>, gerd.moellmann <at> gmail.com,
>  inigoserna <at> gmx.com, 77961 <at> debbugs.gnu.org
> Date: Wed, 23 Apr 2025 15:44:03 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >>    BEWARE: Most uses of this macro introduce bugs.
> >> 
> >> is much too mild in my opinion.  AFAICT the first two calls in shr.el
> >> could be avoided by using 'buffer-text-pixel-size'.  The one in
> >> 'shr-render-td-1' looks worse - since it calls 'shr-pixel-buffer-width'
> >> it nests one 'save-window-excursion' call into another which is simply
> >> evil.
> >
> > Thanks.  Patches welcome to avoid using save-window-excursion in
> > shr.el.
> 
> It is difficult until there is a clear picture why
> 
> (save-window-excursion
>           ;; Avoid errors if the selected window is a dedicated one,
>           ;; and they just want to insert a document into it.
>           (set-window-dedicated-p nil nil)
> 	  (set-window-buffer nil (current-buffer))
> 	  (car (window-text-pixel-size nil (line-beginning-position) (point))))
> 
> dance is even necessary.

Figuring that out is part of the job, AFAIU.  (We could try asking
Lars, if he remembers and if he will chime in.)

> For example, `string-pixel-width' somehow does not need it.

string-pixel-width didn't exist when this part of shr.el was
implemented.  And in addition, the fact that we still keep fixing
string-pixel-width so it does TRT in some complicated cases (the last
change was just a month ago), and its code becomes more and more
complex as result, is also telltale.

Previous Next

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