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

From: Gerd Möllmann <[email-masked]>
Date: Tue, 22 Apr 2025 11:29:35 +0200

Iñigo Serna <[email-masked]> writes:

> On 22 April 2025 at 10:02 +02, Gerd Möllmann
> <[email-masked]> 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.