bug#77961: 31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5

[Iñigo Serna]

On 22 April 2025 at 10:02 +02, Gerd Möllmann 
<gerd.moellmann@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
Description: Text document

profiler-patched.txt
Description: Text document

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> > Ihor Radchenko <yantar92@posteo.net> writes:
> >
> > > Iñigo Serna <inigoserna@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.