> 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