bug#36032: 27.0.50; Massive GC when shift-selecting text in HELLO

[martin rudalics]

> To reproduce:
>
>    emacs -Q
>    C-h h
>    C-SPC
>    C-f C-f C-f ....
>
> You will see a ~0.5 sec delay after each C-f, before its effect of
> extending the region is visible.  The reason is GC after every
> keystroke, and it seems to be caused by the changes in commit 479f51a.
> That commit caused mode-line-default-help-echo to be called each time
> Emacs needs to redisplay the mode line, and that seems to produce lots
> of garbage, at least with the HELLO file.

Here the delays are considerably larger (one second at least) and
there is at least one GC after each keystroke, sometimes two.  But I
can't confirm the remainder of what you say.  Attached find two small
files.

Loading the first one (show-gc.el) with emacs -Q gives approximately
the same behaviors with Emacs 26.2.50 (which does not have the
'mode-line-default-help-echo' function) and Emacs 27.0.50 - at least
one GC per keystroke here.

Loading the second one (show-gc-he.el) with emacs -Q (Emacs 27.0.50
only) shows that there is one call of 'mode-line-default-help-echo'
per keystroke and I doubt that one such call can produce that much
garbage.

Also, customizing the option 'mode-line-default-help-echo' to nil does
not make any performance difference here.

All tested with 64-bit MSYS2 builds on Windows 10.  If you get
different results please tell me.  Also I have not installed the
Harfbuzz branch so OMMV.

> If this function cannot be optimized to produce less garbage, could we
> perhaps somehow cache the value of the help-echo and not recalculate
> it unless something really changed?

This is certainly a good idea.  But I doubt it would have any impact
in the case at hand.

martin

show-gc.el
Description: Text document

show-gc-he.el
Description: Text document