bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii <eliz@gnu.org>]

severity 71454 wishlist
thanks

> Cc: Jeremy Bryant <jb@jeremybryant.net>, 71454@debbugs.gnu.org
> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 10 Jun 2024 04:18:08 +0200
> 
> > On Jun 10, 2024, at 01:10, Jim Porter <jporterbugs@gmail.com> wrote:
> > 
> > On 6/9/2024 3:17 PM, Kai Ma wrote:
> >>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb@jeremybryant.net> wrote:
> >>> 
> >>> Would you be able to provide a self-contained series of steps starting
> >>> from emacs -Q?
> >> On my machine it is extremely easy to reproduce by simply:
> >> 1. emacs -Q
> >> 2. Switch to *scratch*
> >> 3. Copy the provided text into *scratch*
> >> 4. Emacs will freeze for 17 seconds or so, and it cannot be interrupted by C-g
> > 
> > Is this on MS-Windows, by chance? Using a different set of steps, I can reproduce this issue on MS-Windows (Emacs 29.3), but not on GNU/Linux. Here's what I did:
> > 
> >  emacs -Q
> >  C-h v comint-password-prompt-regexp RET
> 
> 
> I’m using macOS. I apologize for not adding this info to my original report.
> 
> And yes, I can also reproduce the issue with C-h v comint-password-prompt-regexp RET

AFAICT, the problematic part of comint-password-prompt-regexp is this:

  गुप्तशब्द\\|शब्दकूट\\|গুপ্তশব্দ\\|পাসওয়ার্ড\\|ਪਾਸਵਰਡ\\|પાસવર્ડ\\|ପ୍ରବେଶ ସଙ୍କେତ\\|கடவுச்சொல்\\|సంకేతపదము\\|ಗುಪ್ತಪದ\\|അടയാളവാക്ക്\\|රහස්පදය

This has nothing to do with the number of fonts installed on the
system, nor with how Emacs searches for fonts, nor even with the fonts
themselves.  On my system, all of the characters above are displayed
using the same single font.  And yet, even if I insert just a single
character of those, which causes Emacs to find and load that font,
pasting the rest of the string takes several seconds in an unoptimized
build (I expect it to take about 2 sec or less in an optimized build).

Note that if you then paste the same string over and over again, the
display is instantaneous.

My crystal ball says that the expensive part here is character
composition.  The above characters belong to scripts that require
extensive composition rules, take a look at indian.el and its complex
regexps.  Displaying those characters requires the display code to
examine all those regexps, to find the largest composable sequence,
then generate the compositions by calling into Lisp, which then calls
back into C where we call HarfBuzz to produce the font glyphs for the
compositions.  This is expensive, and so Emacs caches each composition
for further use, which explains why subsequent pastes are much faster.

IOW, this is a price we pay for the fact that we make character
compositions infinitely customizable on the Lisp level.

So far, I see no bug here.  Of course, if someone wants to work on
redesign of how Emacs handles character composition, and as part of
such a redesign will make the process much faster, that would be very
welcome.