GNU bug report logs - #71454
30.0.50; Performance issues with font selection

Previous Next

To reply to this bug, email your comments to 71454 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: 30.0.50; Performance issues with font selection
Date: Sun, 9 Jun 2024 20:56:47 +0200

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:

〡〢〣〤〥〦〨〩〸〹〺

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

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

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

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

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

Message #8 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Sun, 09 Jun 2024 23:10:56 +0100

Kai Ma <justksqsf <at> 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?

Message #11 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 00:17:55 +0200

> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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

Message #14 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Sun, 09 Jun 2024 23:34:45 +0100

Kai Ma <justksqsf <at> gmail.com> writes:

>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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?

Message #17 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Kai Ma <justksqsf <at> gmail.com>, Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Sun, 9 Jun 2024 16:10:07 -0700

On 6/9/2024 3:17 PM, Kai Ma wrote:
> 
>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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

Message #20 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 04:14:40 +0200

> On Jun 10, 2024, at 00:34, Jeremy Bryant <jb <at> jeremybryant.net> wrote:
> 
> Kai Ma <justksqsf <at> gmail.com> writes:
> 
>>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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.

Message #23 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Jeremy Bryant <jb <at> jeremybryant.net>, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 04:18:08 +0200

> On Jun 10, 2024, at 01:10, Jim Porter <jporterbugs <at> gmail.com> wrote:
> 
> On 6/9/2024 3:17 PM, Kai Ma wrote:
>>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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

Message #26 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 14:55:06 +0300

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

Message #29 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: jporterbugs <at> gmail.com, jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 14:53:36 +0300

severity 71454 wishlist
thanks

> Cc: Jeremy Bryant <jb <at> jeremybryant.net>, 71454 <at> debbugs.gnu.org
> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Mon, 10 Jun 2024 04:18:08 +0200
> 
> > On Jun 10, 2024, at 01:10, Jim Porter <jporterbugs <at> gmail.com> wrote:
> > 
> > On 6/9/2024 3:17 PM, Kai Ma wrote:
> >>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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.

Message #34 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 14:58:01 +0300

> From: Kai Ma <justksqsf <at> 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.

Message #37 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 14:34:42 +0200

[Message part 1 (text/plain, inline)]

> On Jun 10, 2024, at 13:58, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Kai Ma <justksqsf <at> 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.

[Message part 2 (text/html, inline)]

Message #40 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jeremy Bryant <jb <at> jeremybryant.net>, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 14:35:50 +0200

> On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Cc: 71454 <at> debbugs.gnu.org
>> From: Kai Ma <justksqsf <at> gmail.com>
>> Date: Mon, 10 Jun 2024 00:17:55 +0200
>> 
>> 
>>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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.

Message #43 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 15:04:18 +0300

> Cc: 71454 <at> debbugs.gnu.org
> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Mon, 10 Jun 2024 04:14:40 +0200
> 
> 
> 
> > On Jun 10, 2024, at 00:34, Jeremy Bryant <jb <at> jeremybryant.net> wrote:
> > 
> > Kai Ma <justksqsf <at> gmail.com> writes:
> > 
> >>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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.

Message #46 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 16:03:41 +0300

> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Mon, 10 Jun 2024 14:34:42 +0200
> Cc: 71454 <at> 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).

Message #49 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 15:59:52 +0300

> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Mon, 10 Jun 2024 14:35:50 +0200
> Cc: Jeremy Bryant <jb <at> jeremybryant.net>,
>  71454 <at> debbugs.gnu.org
> 
> 
> 
> > On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> Cc: 71454 <at> debbugs.gnu.org
> >> From: Kai Ma <justksqsf <at> gmail.com>
> >> Date: Mon, 10 Jun 2024 00:17:55 +0200
> >> 
> >> 
> >>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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?

Message #52 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Kai Ma <justksqsf <at> gmail.com>, 71454 <at> debbugs.gnu.org, jb <at> jeremybryant.net
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 18:42:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Kai Ma <justksqsf <at> gmail.com>
>> Date: Mon, 10 Jun 2024 14:35:50 +0200
>> Cc: Jeremy Bryant <jb <at> jeremybryant.net>,
>>  71454 <at> debbugs.gnu.org
>> 
>> 
>> 
>> > On Jun 10, 2024, at 13:55, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> > 
>> >> Cc: 71454 <at> debbugs.gnu.org
>> >> From: Kai Ma <justksqsf <at> gmail.com>
>> >> Date: Mon, 10 Jun 2024 00:17:55 +0200
>> >> 
>> >> 
>> >>> On Jun 10, 2024, at 00:10, Jeremy Bryant <jb <at> 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.)

Message #55 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: justksqsf <at> gmail.com, 71454 <at> debbugs.gnu.org, jb <at> jeremybryant.net
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 20:35:42 +0300

> Date: Mon, 10 Jun 2024 09:31:53 -0700
> Cc: jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> 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.

Message #58 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71454 <at> debbugs.gnu.org,
 Jeremy Bryant <jb <at> jeremybryant.net>
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 20:05:41 +0200

Kai Ma <justksqsf <at> gmail.com> writes:

>> On Jun 10, 2024, at 18:42, Gerd Möllmann <gerd.moellmann <at> 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).

Message #61 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71454 <at> debbugs.gnu.org,
 Jeremy Bryant <jb <at> jeremybryant.net>
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 19:36:24 +0200

> On Jun 10, 2024, at 18:42, Gerd Möllmann <gerd.moellmann <at> 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).

Message #64 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Kai Ma <justksqsf <at> gmail.com>
Cc: jb <at> jeremybryant.net, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Mon, 10 Jun 2024 09:31:53 -0700

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

Message #67 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
Subject: Re: 30.0.50; Performance issues with font selection
Date: Fri, 27 Sep 2024 00:42:04 +0200

[Message part 1 (text/plain, inline)]

I got back to this problem today and have some initial ideas.

I did some profiling and the profiler clearly shows that most CPU time was in macfont_list and CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached below) So yes, it’s a Mac-only problem.

macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors for n times, where n is the number of installed fonts. It seems CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and we should minimize the use of it.

I did a quick proof-of-concept patch (attached) that removes the outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors itself to search for fonts). And now I no longer experience long delays. It’s not complete as I haven’t adapted & incorporated mac_font_create_preferred_family_for_attributes yet.

I don’t see noticeable font differences after the change on the files I’m working on. I would like to gather some feedback from the more experienced on whether this is a promising solution or not. If it is, I will refine it into a formal patch.

[0001-Proof-of-concept-patch-for-macfont_list.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Profile (before patch):

[CleanShot 2024-09-27 at 00.02.47@2x.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

(You could see the hang on my machine could be as bad as 10 seconds.)

Profile (after patch):

[CleanShot 2024-09-27 at 00.31.33@2x.png (image/png, inline)]

[Message part 7 (text/plain, inline)]

> On Jun 9, 2024, at 20:56, Kai Ma <justksqsf <at> gmail.com> wrote:
> 
> 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:
> 
> 〡〢〣〤〥〦〨〩〸〹〺
> 
> [ū, ú, ű, ǔ, ù, ȕ, û, ŭ, ȗ, ü, ǖ, ǘ, ǚ, ǜ, ů, ũ, ᵤ, ᵘ, ʉ, ᶶ, ủ, ų, ṷ, ụ,
> ṳ, ṵ, ư, ʊ, ᶷ, ᵿ, ᶙ, ṻ, ṹ, ứ, ừ, ữ, ử, ự, ꭒ, ꭟ, ꝸ, ꭎ, ꭏ, ᴝ, ᵙ, ᴞ]
> 
> [ü, ǖ, ǘ, ǚ, ǜ, ṽ, ᵛ, ᵥ, ṿ, ꝟ, ʋ, ᶹ, ᶌ, ⱴ, ⱱ, ỽ, ʌ, ᶺ]
> 
> [Ü, Ǖ, Ǘ, Ǚ, Ǜ, Ṽ, ᴠ, ⱽ, Ṿ, Ꝟ, Ʋ, Ỽ, Ʌ ]
> 
> [ ₀, ₁, ₂, ₃, ₄, ₅, ₆, ₇, ₈, ₉, ₊, ₋, ₌, ₍, ₎, ‸, ᴀ, ₐ, ᴁ, ʙ, ᴃ, ᵦ, ᴄ, ᴐ, ᴒ, ᴅ, ᴆ, ᴇ, ₑ, ₔ, ᵩ, ɢ, ʛ, ᴦ, ᵧ, ʜ, ₕ, ɪ, ᵻ, ᵢ, ᴊ, ⱼ, ᴋ, ₖ, ʟ, ₗ, ᴌ, ᴧ, ᴍ, ₘ, ꟺ, ɴ, ᴎ, ₙ, ᴏ, ₒ, ɶ, ʘ, ᴓ, ᴑ, ᴘ, ₚ, ᴨ, ᴪ, ʀ, ᵣ, ᴙ, ʁ, ᴚ, ᵨ, ₛ, ᴛ, ₜ, ᴜ, ᵤ, ᵾ, ᴠ, ᵥ, ᴡ, ₓ, ᵪ, ʏ, ᴢ, ᴣ ]
> 
> [ 五, 伍, ₅, ⁵, Ⅴ, ⅴ, ⑤, ➄, ❺, ➎, ⓹, ⑸, ⒌, ５, ㊄, ㈤, 㐅, 㠪, 𠄡 ]
> 

Message #70 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>, Alan Third <alan <at> idiocy.org>,
 Po Lu <luangruo <at> yahoo.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Fri, 27 Sep 2024 09:32:50 +0300

> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Fri, 27 Sep 2024 00:42:04 +0200
> 
> I got back to this problem today and have some initial ideas.
> 
> I did some profiling and the profiler clearly shows that most CPU time was in macfont_list and CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached below) So yes, it’s a Mac-only problem.
> 
> macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors for n times, where n is the number of installed fonts. It seems CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and we should minimize the use of it.
> 
> I did a quick proof-of-concept patch (attached) that removes the outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors itself to search for fonts). And now I no longer experience long delays. It’s not complete as I haven’t adapted & incorporated mac_font_create_preferred_family_for_attributes yet.
> 
> I don’t see noticeable font differences after the change on the files I’m working on. I would like to gather some feedback from the more experienced on whether this is a promising solution or not. If it is, I will refine it into a formal patch.

Thanks.  I'm adding a few people in the hope that they could comment
on the patch, or maybe try it and provide feedback.

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

This part, about _any_ unusual characters causing a significant delay,
seems to imply that the default fontset is not set up correctly on
your system (or maybe in general on macOS), or perhaps that the way
the fontsets are used on macOS is very different from other systems.
For starters, are the fonts that Emacs selects for the characters you
used for testing different from the fonts defined by fontset-default
for those characters?  If so, what happens if you modify
fontset-default (using set-fontset-font) to specify for these
characters the same fonts as what Emacs selects with the default value
of fontset-default? does font selection become much faster (it
should)?

If specifying the precise font in the fontset doesn't speed up font
selection, then something is very wrong with how fontsets are used on
macOS.  Emacs comes with the default value of fontset-default that is
already configured for many characters, and the ones you show should
be included.  So I'm puzzled why you experience such long delays when
some of those characters are used.

It could also be the matter of selecting the default face's font.  For
best results, it should be a font that covers many popular scripts, at
the very least Latin, Cyrillic, and Greek.  Judging by the "unusual"
characters you show, it sounds like Latin characters are not well
covered by your default face's font?  If so, perhaps choosing a font
with better coverage will make the situation better for you?

Message #73 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Alan Third <alan <at> idiocy.org>, 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Fri, 27 Sep 2024 09:51:06 +0200

[Message part 1 (text/plain, inline)]

> On Sep 27, 2024, at 08:32, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>>> 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.
> 
> This part, about _any_ unusual characters causing a significant delay,
> seems to imply that the default fontset is not set up correctly on
> your system (or maybe in general on macOS), or perhaps that the way
> the fontsets are used on macOS is very different from other systems.
> For starters, are the fonts that Emacs selects for the characters you
> used for testing different from the fonts defined by fontset-default
> for those characters?  If so, what happens if you modify
> fontset-default (using set-fontset-font) to specify for these
> characters the same fonts as what Emacs selects with the default value
> of fontset-default? does font selection become much faster (it
> should)?

Yes, if I manually set the font, it becomes instant.

> If specifying the precise font in the fontset doesn't speed up font
> selection, then something is very wrong with how fontsets are used on
> macOS.  Emacs comes with the default value of fontset-default that is
> already configured for many characters, and the ones you show should
> be included.  So I'm puzzled why you experience such long delays when
> some of those characters are used.
> 
> It could also be the matter of selecting the default face's font.  For
> best results, it should be a font that covers many popular scripts, at
> the very least Latin, Cyrillic, and Greek.  Judging by the "unusual"
> characters you show, it sounds like Latin characters are not well
> covered by your default face's font?  If so, perhaps choosing a font
> with better coverage will make the situation better for you?

It would not eliminate the problem though. I’m editing a file with new emojis in Unicode 16 (released recently in September) and the emojis are glyphless currently. I experience unbearable delays whenever such glyphs are visible.

Based on the profiling, my guess is that CTFontDescriptorCreateMatchingFontDescriptors is doing a linear search internally (it probably didn’t just pick the specified by the font family?), so macfont_list is accidentally O(n^2).  This (if true) should explain why it’s so slow.

[Message part 2 (text/html, inline)]

Message #76 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: luangruo <at> yahoo.com, gerd.moellmann <at> gmail.com, alan <at> idiocy.org,
 71454 <at> debbugs.gnu.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Fri, 27 Sep 2024 13:29:13 +0300

> From: Kai Ma <justksqsf <at> gmail.com>
> Date: Fri, 27 Sep 2024 09:51:06 +0200
> Cc: Alan Third <alan <at> idiocy.org>,
>  Po Lu <luangruo <at> yahoo.com>,
>  Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>  71454 <at> debbugs.gnu.org
> 
>  This part, about _any_ unusual characters causing a significant delay,
>  seems to imply that the default fontset is not set up correctly on
>  your system (or maybe in general on macOS), or perhaps that the way
>  the fontsets are used on macOS is very different from other systems.
>  For starters, are the fonts that Emacs selects for the characters you
>  used for testing different from the fonts defined by fontset-default
>  for those characters?  If so, what happens if you modify
>  fontset-default (using set-fontset-font) to specify for these
>  characters the same fonts as what Emacs selects with the default value
>  of fontset-default? does font selection become much faster (it
>  should)?
> 
> Yes, if I manually set the font, it becomes instant.

Thanks, so it means finding a font that matches the default font's
spec is indeed slow on your system.

I wonder if this is a general issue with macOS, or just with the
version and/or configuration you are running.

>  It could also be the matter of selecting the default face's font.  For
>  best results, it should be a font that covers many popular scripts, at
>  the very least Latin, Cyrillic, and Greek.  Judging by the "unusual"
>  characters you show, it sounds like Latin characters are not well
>  covered by your default face's font?  If so, perhaps choosing a font
>  with better coverage will make the situation better for you?
> 
> It would not eliminate the problem though.

I didn't mean that it will.  However, being able to display more
characters without delays is a Good Thing regardless.

> Based on the profiling, my guess is that CTFontDescriptorCreateMatchingFontDescriptors is doing a linear
> search internally (it probably didn’t just pick the specified by the font family?), so macfont_list is accidentally O
> (n^2).  This (if true) should explain why it’s so slow.

Yes, you said that in your original report.

Message #79 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Kai Ma <justksqsf <at> gmail.com>,
 71454 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Sat, 28 Sep 2024 05:36:32 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Kai Ma <justksqsf <at> gmail.com>
>> Date: Fri, 27 Sep 2024 00:42:04 +0200
>> 
>> I got back to this problem today and have some initial ideas.
>> 
>> I did some profiling and the profiler clearly shows that most CPU
>> time was in macfont_list and
>> CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached
>> below) So yes, it’s a Mac-only problem.
>> 
>> macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors
>> for n times, where n is the number of installed fonts. It seems
>> CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and
>> we should minimize the use of it.
>> 
>> I did a quick proof-of-concept patch (attached) that removes the
>> outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors
>> itself to search for fonts). And now I no longer experience long
>> delays. It’s not complete as I haven’t adapted & incorporated
>> mac_font_create_preferred_family_for_attributes yet.
>> 
>> I don’t see noticeable font differences after the change on the
>> files I’m working on. I would like to gather some feedback from the
>> more experienced on whether this is a promising solution or not. If
>> it is, I will refine it into a formal patch.
>
> Thanks.  I'm adding a few people in the hope that they could comment
> on the patch, or maybe try it and provide feedback.

I haven't tried the patch because I can't reproduce the problem and I
don't use much beyond Latin-1 so I think chances are low that I'd see
anyting breaking with the patch.

But looking at the patch, which mostly removes stuff from macfont_list,
I wonder if/how that can be semeantically equalivalent to the existing
code.

Just saying, I'm definitely not an expert in this area.

Adding YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, the original
author.

Message #82 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 mituharu <at> math.s.chiba-u.ac.jp
Cc: luangruo <at> yahoo.com, justksqsf <at> gmail.com, 71454 <at> debbugs.gnu.org,
 alan <at> idiocy.org
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Sat, 12 Oct 2024 14:20:21 +0300

Ping!

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Kai Ma <justksqsf <at> gmail.com>,  Alan Third <alan <at> idiocy.org>,  Po Lu
>  <luangruo <at> yahoo.com>,  71454 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu
>  <mituharu <at> math.s.chiba-u.ac.jp>
> Date: Sat, 28 Sep 2024 05:36:32 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Kai Ma <justksqsf <at> gmail.com>
> >> Date: Fri, 27 Sep 2024 00:42:04 +0200
> >> 
> >> I got back to this problem today and have some initial ideas.
> >> 
> >> I did some profiling and the profiler clearly shows that most CPU
> >> time was in macfont_list and
> >> CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached
> >> below) So yes, it’s a Mac-only problem.
> >> 
> >> macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors
> >> for n times, where n is the number of installed fonts. It seems
> >> CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and
> >> we should minimize the use of it.
> >> 
> >> I did a quick proof-of-concept patch (attached) that removes the
> >> outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors
> >> itself to search for fonts). And now I no longer experience long
> >> delays. It’s not complete as I haven’t adapted & incorporated
> >> mac_font_create_preferred_family_for_attributes yet.
> >> 
> >> I don’t see noticeable font differences after the change on the
> >> files I’m working on. I would like to gather some feedback from the
> >> more experienced on whether this is a promising solution or not. If
> >> it is, I will refine it into a formal patch.
> >
> > Thanks.  I'm adding a few people in the hope that they could comment
> > on the patch, or maybe try it and provide feedback.
> 
> I haven't tried the patch because I can't reproduce the problem and I
> don't use much beyond Latin-1 so I think chances are low that I'd see
> anyting breaking with the patch.
> 
> But looking at the patch, which mostly removes stuff from macfont_list,
> I wonder if/how that can be semeantically equalivalent to the existing
> code.
> 
> Just saying, I'm definitely not an expert in this area.
> 
> Adding YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, the original
> author.
> 

Message #85 received at 71454 <at> debbugs.gnu.org (full text, mbox):

From: Kai Ma <justksqsf <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 luangruo <at> yahoo.com, alan <at> idiocy.org, 71454 <at> debbugs.gnu.org,
 mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#71454: 30.0.50; Performance issues with font selection
Date: Tue, 15 Oct 2024 22:34:59 +0200

[Message part 1 (text/plain, inline)]

I’ve been personally using my change for some while and I didn’t notice any regression (only for my use cases of course).  Attached is the final patch.  Hopefully it can encourage more NSport users to test it.

[0001-Improve-the-performance-of-font-selection-on-macOS.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

> On Oct 12, 2024, at 13:20, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> Ping!
> 
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Kai Ma <justksqsf <at> gmail.com>,  Alan Third <alan <at> idiocy.org>,  Po Lu
>> <luangruo <at> yahoo.com>,  71454 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu
>> <mituharu <at> math.s.chiba-u.ac.jp>
>> Date: Sat, 28 Sep 2024 05:36:32 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>>>> From: Kai Ma <justksqsf <at> gmail.com>
>>>> Date: Fri, 27 Sep 2024 00:42:04 +0200
>>>> 
>>>> I got back to this problem today and have some initial ideas.
>>>> 
>>>> I did some profiling and the profiler clearly shows that most CPU
>>>> time was in macfont_list and
>>>> CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached
>>>> below) So yes, it’s a Mac-only problem.
>>>> 
>>>> macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors
>>>> for n times, where n is the number of installed fonts. It seems
>>>> CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and
>>>> we should minimize the use of it.
>>>> 
>>>> I did a quick proof-of-concept patch (attached) that removes the
>>>> outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors
>>>> itself to search for fonts). And now I no longer experience long
>>>> delays. It’s not complete as I haven’t adapted & incorporated
>>>> mac_font_create_preferred_family_for_attributes yet.
>>>> 
>>>> I don’t see noticeable font differences after the change on the
>>>> files I’m working on. I would like to gather some feedback from the
>>>> more experienced on whether this is a promising solution or not. If
>>>> it is, I will refine it into a formal patch.
>>> 
>>> Thanks.  I'm adding a few people in the hope that they could comment
>>> on the patch, or maybe try it and provide feedback.
>> 
>> I haven't tried the patch because I can't reproduce the problem and I
>> don't use much beyond Latin-1 so I think chances are low that I'd see
>> anyting breaking with the patch.
>> 
>> But looking at the patch, which mostly removes stuff from macfont_list,
>> I wonder if/how that can be semeantically equalivalent to the existing
>> code.
>> 
>> Just saying, I'm definitely not an expert in this area.
>> 
>> Adding YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, the original
>> author.
>> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.