bug#71454: 30.0.50; Performance issues with font selection

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

Recently, I have the need of editing files with extraordinary ranges of
Unicode code points, and the performance problem with font selection
becomes too obvious to ignore.

I have currently (length (font-family-list)) = 582 font families
installed. And whenever I input some ununsual characters, Emacs will
freeze for seconds until I am able to do anything else.  Worse, the
freeze delay for each character will add up.  And whenver the face
changes (including hl-line-mode), or I switched to another buffer for
some time, there will be a delay again.

I'm pretty sure this is due to font selection, because Emacs won't
freeze if I configure manually the fallback fonts for each 'exotic'
script I encounter.

For testing, there are some such characters in my file:

〡〢〣〤〥〦〨〩〸〹〺

[ū, ú, ű, ǔ, ù, ȕ, û, ŭ, ȗ, ü, ǖ, ǘ, ǚ, ǜ, ů, ũ, ᵤ, ᵘ, ʉ, ᶶ, ủ, ų, ṷ, ụ,
ṳ, ṵ, ư, ʊ, ᶷ, ᵿ, ᶙ, ṻ, ṹ, ứ, ừ, ữ, ử, ự, ꭒ, ꭟ, ꝸ, ꭎ, ꭏ, ᴝ, ᵙ, ᴞ]

[ü, ǖ, ǘ, ǚ, ǜ, ṽ, ᵛ, ᵥ, ṿ, ꝟ, ʋ, ᶹ, ᶌ, ⱴ, ⱱ, ỽ, ʌ, ᶺ]

[Ü, Ǖ, Ǘ, Ǚ, Ǜ, Ṽ, ᴠ, ⱽ, Ṿ, Ꝟ, Ʋ, Ỽ, Ʌ ]

[ ₀, ₁, ₂, ₃, ₄, ₅, ₆, ₇, ₈, ₉, ₊, ₋, ₌, ₍, ₎, ‸, ᴀ, ₐ, ᴁ, ʙ, ᴃ, ᵦ, ᴄ, ᴐ, ᴒ, ᴅ, ᴆ, ᴇ, ₑ, ₔ, ᵩ, ɢ, ʛ, ᴦ, ᵧ, ʜ, ₕ, ɪ, ᵻ, ᵢ, ᴊ, ⱼ, ᴋ, ₖ, ʟ, ₗ, ᴌ, ᴧ, ᴍ, ₘ, ꟺ, ɴ, ᴎ, ₙ, ᴏ, ₒ, ɶ, ʘ, ᴓ, ᴑ, ᴘ, ₚ, ᴨ, ᴪ, ʀ, ᵣ, ᴙ, ʁ, ᴚ, ᵨ, ₛ, ᴛ, ₜ, ᴜ, ᵤ, ᵾ, ᴠ, ᵥ, ᴡ, ₓ, ᵪ, ʏ, ᴢ, ᴣ ]

[ 五, 伍, ₅, ⁵, Ⅴ, ⅴ, ⑤, ➄, ❺, ➎, ⓹, ⑸, ⒌, ５, ㊄, ㈤, 㐅, 㠪, 𠄡 ]

bug#71454: 30.0.50; Performance issues with font selection

[Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kai Ma <justksqsf@gmail.com> writes:

> Recently, I have the need of editing files with extraordinary ranges of
> Unicode code points, and the performance problem with font selection
> becomes too obvious to ignore.
>
> I have currently (length (font-family-list)) = 582 font families
> installed. And whenever I input some ununsual characters, Emacs will
> freeze for seconds until I am able to do anything else.  Worse, the
> freeze delay for each character will add up.  And whenver the face
> changes (including hl-line-mode), or I switched to another buffer for
> some time, there will be a delay again.
>
> I'm pretty sure this is due to font selection, because Emacs won't
> freeze if I configure manually the fallback fonts for each 'exotic'
> script I encounter.
>
> For testing, there are some such characters in my file:
>
> 〡〢〣〤〥〦〨〩〸〹〺
>
> [ū, ú, ű, ǔ, ù, ȕ, û, ŭ, ȗ, ü, ǖ, ǘ, ǚ, ǜ, ů, ũ, ᵤ, ᵘ, ʉ, ᶶ, ủ, ų, ṷ, ụ,
> ṳ, ṵ, ư, ʊ, ᶷ, ᵿ, ᶙ, ṻ, ṹ, ứ, ừ, ữ, ử, ự, ꭒ, ꭟ, ꝸ, ꭎ, ꭏ, ᴝ, ᵙ, ᴞ]
>
> [ü, ǖ, ǘ, ǚ, ǜ, ṽ, ᵛ, ᵥ, ṿ, ꝟ, ʋ, ᶹ, ᶌ, ⱴ, ⱱ, ỽ, ʌ, ᶺ]
>
> [Ü, Ǖ, Ǘ, Ǚ, Ǜ, Ṽ, ᴠ, ⱽ, Ṿ, Ꝟ, Ʋ, Ỽ, Ʌ ]
>
> [ ₀, ₁, ₂, ₃, ₄, ₅, ₆, ₇, ₈, ₉, ₊, ₋, ₌, ₍, ₎, ‸, ᴀ, ₐ, ᴁ, ʙ, ᴃ, ᵦ, ᴄ, ᴐ, ᴒ, ᴅ, ᴆ, ᴇ, ₑ, ₔ, ᵩ, ɢ, ʛ, ᴦ, ᵧ, ʜ, ₕ, ɪ, ᵻ, ᵢ, ᴊ, ⱼ, ᴋ, ₖ, ʟ, ₗ, ᴌ, ᴧ, ᴍ, ₘ, ꟺ, ɴ, ᴎ, ₙ, ᴏ, ₒ, ɶ, ʘ, ᴓ, ᴑ, ᴘ, ₚ, ᴨ, ᴪ, ʀ, ᵣ, ᴙ, ʁ, ᴚ, ᵨ, ₛ, ᴛ, ₜ, ᴜ, ᵤ, ᵾ, ᴠ, ᵥ, ᴡ, ₓ, ᵪ, ʏ, ᴢ, ᴣ ]
>
> [ 五, 伍, ₅, ⁵, Ⅴ, ⅴ, ⑤, ➄, ❺, ➎, ⓹, ⑸, ⒌, ５, ㊄, ㈤, 㐅, 㠪, 𠄡 ]

Would you be able to provide a self-contained series of steps starting
from emacs -Q?

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

> 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

bug#71454: 30.0.50; Performance issues with font selection

[Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Kai Ma <justksqsf@gmail.com> writes:

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

I am unable to reproduce this bug.

Please could you specify exactly which version of Emacs you are using?

bug#71454: 30.0.50; Performance issues with font selection

[Jim Porter]

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

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

> On Jun 10, 2024, at 00:34, Jeremy Bryant <jb@jeremybryant.net> wrote:
> 
> Kai Ma <justksqsf@gmail.com> writes:
> 
>>> 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
> 
> I am unable to reproduce this bug.
> 
> Please could you specify exactly which version of Emacs you are using?

I’m using Emacs master branch (commit 7f8ded2a85d) on macOS.

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

> 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

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

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.

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> Cc: 71454@debbugs.gnu.org
> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 10 Jun 2024 00:17:55 +0200
> 
> 
> > 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

I cannot reproduce this, I get an almost instantaneous redisplay with
those characters.

When your Emacs eventually displays the text, how many characters are
shown as boxes with hex code, and which ones are those?

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> From: Kai Ma <justksqsf@gmail.com>
> Date: Sun, 9 Jun 2024 20:56:47 +0200
> 
> I have currently (length (font-family-list)) = 582 font families
> installed. And whenever I input some ununsual characters, Emacs will
> freeze for seconds until I am able to do anything else.  Worse, the
> freeze delay for each character will add up.  And whenver the face
> changes (including hl-line-mode), or I switched to another buffer for
> some time, there will be a delay again.

FTR, I have 553 font families, and I see no significant delay when
pasting the characters you show.

> I'm pretty sure this is due to font selection, because Emacs won't
> freeze if I configure manually the fallback fonts for each 'exotic'
> script I encounter.

If this is the case, please tell the details: which fonts you need to
configure manually to eliminate the delay.

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> Cc: 71454@debbugs.gnu.org
> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 10 Jun 2024 04:14:40 +0200
> 
> 
> 
> > On Jun 10, 2024, at 00:34, Jeremy Bryant <jb@jeremybryant.net> wrote:
> > 
> > Kai Ma <justksqsf@gmail.com> writes:
> > 
> >>> 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
> > 
> > I am unable to reproduce this bug.
> > 
> > Please could you specify exactly which version of Emacs you are using?
> 
> I’m using Emacs master branch (commit 7f8ded2a85d) on macOS.

Maybe this is specific to the macOS font back-end, which AFAIU is a
special one used only on macOS.

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]



> On Jun 10, 2024, at 13:58, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Kai Ma <justksqsf@gmail.com>
>> Date: Sun, 9 Jun 2024 20:56:47 +0200
>> 
>> I have currently (length (font-family-list)) = 582 font families
>> installed. And whenever I input some ununsual characters, Emacs will
>> freeze for seconds until I am able to do anything else.  Worse, the
>> freeze delay for each character will add up.  And whenver the face
>> changes (including hl-line-mode), or I switched to another buffer for
>> some time, there will be a delay again.
> 
> FTR, I have 553 font families, and I see no significant delay when
> pasting the characters you show.
> 
>> I'm pretty sure this is due to font selection, because Emacs won't
>> freeze if I configure manually the fallback fonts for each 'exotic'
>> script I encounter.
> 
> If this is the case, please tell the details: which fonts you need to
> configure manually to eliminate the delay.


I currently use the following config:

(set-fontset-font t 'han "PingFang TC")
(set-fontset-font t 'kana "PingFang TC")
(set-fontset-font t 'kanbun "PingFang TC")
(set-fontset-font t 'hangul "PingFang TC")
(set-fontset-font t 'cjk-misc "PingFang TC")
(set-fontset-font t 'unicode "PingFang TC" nil 'append)
(set-fontset-font t 'unicode (font-spec :family "Apple Color Emoji") nil 'prepend)
(dolist (thfont '("TH-Feon" "TH-Sy-P0" "TH-Sy-P2" "TH-Sy-P16" "TH-Tshyn-P0"))
  (set-fontset-font t 'unicode thfont nil 'append))

PingFang TC and Apple Color Emoji are built into macOS, and TH-* fonts are from the Internet to cover a majority of the Unicode code points.

For example, 〡〢〣〤〥〦〨〩〸〹〺 belongs to cjk-misc script, and I have to specify a font for it to avoid delays.


[-- Attachment #2: Type: text/html, Size: 2440 bytes --]

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

> On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 71454@debbugs.gnu.org
>> From: Kai Ma <justksqsf@gmail.com>
>> Date: Mon, 10 Jun 2024 00:17:55 +0200
>> 
>> 
>>> 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
> 
> I cannot reproduce this, I get an almost instantaneous redisplay with
> those characters.
> 
> When your Emacs eventually displays the text, how many characters are
> shown as boxes with hex code, and which ones are those?

None are hex code here. They eventually get displayed, but it takes a long time.

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 10 Jun 2024 14:35:50 +0200
> Cc: Jeremy Bryant <jb@jeremybryant.net>,
>  71454@debbugs.gnu.org
> 
> 
> 
> > On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> Cc: 71454@debbugs.gnu.org
> >> From: Kai Ma <justksqsf@gmail.com>
> >> Date: Mon, 10 Jun 2024 00:17:55 +0200
> >> 
> >> 
> >>> 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
> > 
> > I cannot reproduce this, I get an almost instantaneous redisplay with
> > those characters.
> > 
> > When your Emacs eventually displays the text, how many characters are
> > shown as boxes with hex code, and which ones are those?
> 
> None are hex code here. They eventually get displayed, but it takes a long time.

Then it definitely sounds like macOS specific.  Does anyone know how
Emacs on macOS searches for fonts, and whether there are any
font-caching facilities, either in Emacs or by the OS?

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> From: Kai Ma <justksqsf@gmail.com>
> Date: Mon, 10 Jun 2024 14:34:42 +0200
> Cc: 71454@debbugs.gnu.org
> 
> I currently use the following config:
> 
> (set-fontset-font t 'han "PingFang TC")
> (set-fontset-font t 'kana "PingFang TC")
> (set-fontset-font t 'kanbun "PingFang TC")
> (set-fontset-font t 'hangul "PingFang TC")
> (set-fontset-font t 'cjk-misc "PingFang TC")
> (set-fontset-font t 'unicode "PingFang TC" nil 'append)
> (set-fontset-font t 'unicode (font-spec :family "Apple Color Emoji") nil 'prepend)
> (dolist (thfont '("TH-Feon" "TH-Sy-P0" "TH-Sy-P2" "TH-Sy-P16" "TH-Tshyn-P0"))
>   (set-fontset-font t 'unicode thfont nil 'append))
> 
> PingFang TC and Apple Color Emoji are built into macOS, and TH-* fonts are from the Internet to cover a
> majority of the Unicode code points.
> 
> For example, 〡〢〣〤〥〦〨〩〸〹〺 belongs to cjk-misc script, and I have to specify a font for it to avoid
> delays.

FWIW, I get instantaneous display when I copy/paste that text into an
"emacs -Q" I just started, even though I have no fonts for the last 3
characters (which means Emacs searches all the fonts installed on the
system).

bug#71454: 30.0.50; Performance issues with font selection

[Jim Porter]

On 6/10/2024 4:53 AM, Eli Zaretskii wrote:
> 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.

That would show up in a profile, right? Here's what I get when I start 
"emacs -Q", start profiling, and then call "C-h v 
comint-password-prompt-regexp RET". It's not the most interesting 
profile since most of it is probably in C code. I do see 
'auto-compose-chars' in there, however it's got ~0% of the samples from 
the profiler.

I haven't had time to dig into this in any great depth, so this profile 
may of course turn out to be entirely useless...

          910  98% - command-execute
          907  98%  - funcall-interactively
          907  98%   - describe-variable
          907  98%    - help--window-setup
          905  98%     - help-window-setup
            2   0%      - help-window-display-message
            2   0%         auto-compose-chars
            1   0%     - #<compiled 0x14e8696a6b1e2e3f>
            1   0%      - cl-prin1-to-string
            1   0%       - byte-code
            1   0%        - cl-generic-define-method
            1   0%         - cl--generic-make-function
            1   0%          - cl--generic-make-next-function
            1   0%           - cl--generic-get-dispatcher
            1   0%            - byte-compile
            1   0%             - #<subr 
F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_50>
            1   0%                byte-compile-top-level
            1   0%       help-make-xrefs
            3   0%  - byte-code
            2   0%   - read-extended-command
            2   0%    - read-extended-command-1
            2   0%       completing-read-default
            1   0%   - variable-at-point
            1   0%    - find-tag-default
            1   0%       find-tag-default-bounds
           10   1% - ...
            9   0%    Automatic GC
            1   0%  - completion--in-region
            1   0%   - #<compiled -0x68df6976d72fd66>
            1   0%    - apply
            1   0%     - #<compiled -0x1e70b1692b6b395e>
            1   0%      - completion--in-region-1
            1   0%       - completion--do-completion
            1   0%        - completion-try-completion
            1   0%         - completion--nth-completion
            1   0%          - completion--some
            1   0%           - #<compiled 0x3d94d2d3a4c0012>
            1   0%            - completion-basic-try-completion
            1   0%             - completion-boundaries
            1   0%              - help--symbol-completion-table
            1   0%               - help--load-prefixes
            1   0%                - load
            1   0%                   byte-code

bug#71454: 30.0.50; Performance issues with font selection

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kai Ma <justksqsf@gmail.com>
>> Date: Mon, 10 Jun 2024 14:35:50 +0200
>> Cc: Jeremy Bryant <jb@jeremybryant.net>,
>>  71454@debbugs.gnu.org
>> 
>> 
>> 
>> > On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz@gnu.org> wrote:
>> > 
>> >> Cc: 71454@debbugs.gnu.org
>> >> From: Kai Ma <justksqsf@gmail.com>
>> >> Date: Mon, 10 Jun 2024 00:17:55 +0200
>> >> 
>> >> 
>> >>> 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
>> > 
>> > I cannot reproduce this, I get an almost instantaneous redisplay with
>> > those characters.
>> > 
>> > When your Emacs eventually displays the text, how many characters are
>> > shown as boxes with hex code, and which ones are those?
>> 
>> None are hex code here. They eventually get displayed, but it takes a long time.
>
> Then it definitely sounds like macOS specific.  Does anyone know how
> Emacs on macOS searches for fonts, and whether there are any
> font-caching facilities, either in Emacs or by the OS?

Don't know, but the display of the strings mentioned is instantaneous
here too (macOS 14.5), with (length (font-family-list)) == 281.

Maybe use the Font Book app and see if the fonts are all valid? (Start
Font Book, choose All Fonts, select them all with Command + A, then
context menu on the selectoin and choose Validate.)

bug#71454: 30.0.50; Performance issues with font selection

[Eli Zaretskii]

> Date: Mon, 10 Jun 2024 09:31:53 -0700
> Cc: jb@jeremybryant.net, 71454@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 6/10/2024 4:53 AM, Eli Zaretskii wrote:
> > 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.
> 
> That would show up in a profile, right?

No, because Lisp functions called from C don't show in the profile.

> Here's what I get when I start "emacs -Q", start profiling, and then
> call "C-h v comint-password-prompt-regexp RET". It's not the most
> interesting profile since most of it is probably in C code. I do see
> 'auto-compose-chars' in there, however it's got ~0% of the samples
> from the profiler.

As expected, see above.

bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma]

> On Jun 10, 2024, at 18:42, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> […]
> Maybe use the Font Book app and see if the fonts are all valid? (Start
> Font Book, choose All Fonts, select them all with Command + A, then
> context menu on the selectoin and choose Validate.)

I do get some warnings. Font Book shows “52 minor problems were found”. Most are “Duplicate fonts”, but there are also real warnings like “name table structure”.

To clear these warnings, I moved all font files in ~/Library/Fonts elsewhere, but the problem still persists, though the delay for the testing text is much shorter (about 5s now).

bug#71454: 30.0.50; Performance issues with font selection

[Gerd Möllmann]

Kai Ma <justksqsf@gmail.com> writes:

>> On Jun 10, 2024, at 18:42, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>> […]
>> Maybe use the Font Book app and see if the fonts are all valid? (Start
>> Font Book, choose All Fonts, select them all with Command + A, then
>> context menu on the selectoin and choose Validate.)
>
> I do get some warnings. Font Book shows “52 minor problems were
> found”. Most are “Duplicate fonts”, but there are also real warnings
> like “name table structure”.
>
> To clear these warnings, I moved all font files in ~/Library/Fonts
> elsewhere, but the problem still persists, though the delay for the
> testing text is much shorter (about 5s now).

Progress :-).

Rumours have it that one can clear system caches (just to make sure) by
performing a safe boot (https://support.apple.com/en-gb/116946), and
then restarting normally.

And then there is the atsutil command line utitlity. Though I must say
that I never had to use that one, and so I can't say if it's
dangerous... (man atsutil).