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

Previous Next

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