GNU bug report logs - #79773
[PATCH] [NS] Cache Macfont List

Previous Next

To reply to this bug, email your comments to 79773 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: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] [NS] Cache Macfont List
Date: Wed, 05 Nov 2025 19:27:04 +0100

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

This patch caches Macfont list, which prevents building list every call.

This patch is stable, I've been running it for >2 months without any issues.
-- 
Przemysław Alexander Kamiński (vel xlii vel exlee)
https://xlii.space  ||  https://codeberg.org/exlee

[macfont_list_cache_0001.patch (text/x-patch, attachment)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Przemysław Alexander Kamiński <alexander <at> kaminski.se>
Cc: 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Wed, 5 Nov 2025 13:32:56 -0500

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

On Wed, Nov 5, 2025 at 1:28 PM Przemysław Alexander Kamiński <
alexander <at> kaminski.se> wrote:

> This patch caches Macfont list, which prevents building list every call.
>
> This patch is stable, I've been running it for >2 months without any
> issues.
>

Ditto on needing a command to invalidate this cache or all NS caches.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
Cc: 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Wed, 05 Nov 2025 21:36:05 +0200

> From: Przemysław Alexander Kamiński
>  <alexander <at> kaminski.se>
> Date: Wed, 05 Nov 2025 19:27:04 +0100
> 
> This patch caches Macfont list, which prevents building list every call.
> 
> This patch is stable, I've been running it for >2 months without any issues.

Thanks, but once again, I'd like to understand why the NS build needs
this caching whereas other font backends don't.

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

From: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Wed, 05 Nov 2025 20:51:10 +0100

-- 
On Wed, Nov 05, 2025 at 21:36:05 (+0200), Eli Zaretskii wrote:

> Thanks, but once again, I'd like to understand why the NS build needs
> this caching whereas other font backends don't.

I don't think it's foundry, but we circle back to how NS build is
architected. Due to emacs/NS mechanism this list is built more often
than screen is refreshed. 60k/s on my machine. I doubt other backends
are called that often.

-- 
Przemysław Alexander Kamiński (vel xlii vel exlee)
https://xlii.space  ||  https://codeberg.org/exlee

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>, Alan Third <alan <at> idiocy.org>
Cc: 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Wed, 05 Nov 2025 22:04:49 +0200

> From: Przemysław Alexander Kamiński
>  <alexander <at> kaminski.se>
> Cc: 79773 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 20:51:10 +0100
> 
> -- 
> On Wed, Nov 05, 2025 at 21:36:05 (+0200), Eli Zaretskii wrote:
> 
> > Thanks, but once again, I'd like to understand why the NS build needs
> > this caching whereas other font backends don't.
> 
> I don't think it's foundry, but we circle back to how NS build is
> architected. Due to emacs/NS mechanism this list is built more often
> than screen is refreshed. 60k/s on my machine. I doubt other backends
> are called that often.

That's very surprising.  Can you take me through the code which does
that, including the triggers that cause it to be called 60k times per
second?

Thanks.

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

From: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
To: Eli Zaretskii <eliz <at> gnu.org>, Alan Third <alan <at> idiocy.org>
Cc: 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Wed, 05 Nov 2025 21:44:53 +0100

-- 
On Wed, Nov 05, 2025 at 22:04:49 (+0200), Eli Zaretskii wrote:

>> From: Przemysław Alexander Kamiński
>>  <alexander <at> kaminski.se>
>> Cc: 79773 <at> debbugs.gnu.org
>> Date: Wed, 05 Nov 2025 20:51:10 +0100
>> 
>> -- 
>> On Wed, Nov 05, 2025 at 21:36:05 (+0200), Eli Zaretskii wrote:
>> 
>> > Thanks, but once again, I'd like to understand why the NS build needs
>> > this caching whereas other font backends don't.
>> 
>> I don't think it's foundry, but we circle back to how NS build is
>> architected. Due to emacs/NS mechanism this list is built more often
>> than screen is refreshed. 60k/s on my machine. I doubt other backends
>> are called that often.
>
> That's very surprising.  Can you take me through the code which does
> that, including the triggers that cause it to be called 60k times per
> second?

Sure I can do this. It's not a trigger though, but a consequence of
running Emacs and NSApp application on a single thread. I can prepare
exact play-by-play with code references, but that is going to take me
some time.

The gist of it is that we have tick-tock mechanism between NSApp and
Emacs. When NSApp passes control to Emacs most of the allocations are
dropped and when Emacs passes control to NSApp they are redone. This is
by default unbounded, so when Emacs finishes processing events it
immediatelly passes back to NSApp, which will pass back as soon as
rendering is done.

-- 
Przemysław Alexander Kamiński (vel xlii vel exlee)
https://xlii.space  ||  https://codeberg.org/exlee

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
Cc: alan <at> idiocy.org, 79773 <at> debbugs.gnu.org
Subject: Re: bug#79773: [PATCH] [NS] Cache Macfont List
Date: Thu, 06 Nov 2025 08:13:43 +0200

> From: Przemysław Alexander Kamiński
>  <alexander <at> kaminski.se>
> Cc: 79773 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 21:44:53 +0100
> 
> -- 
> On Wed, Nov 05, 2025 at 22:04:49 (+0200), Eli Zaretskii wrote:
> 
> >> I don't think it's foundry, but we circle back to how NS build is
> >> architected. Due to emacs/NS mechanism this list is built more often
> >> than screen is refreshed. 60k/s on my machine. I doubt other backends
> >> are called that often.
> >
> > That's very surprising.  Can you take me through the code which does
> > that, including the triggers that cause it to be called 60k times per
> > second?
> 
> Sure I can do this. It's not a trigger though, but a consequence of
> running Emacs and NSApp application on a single thread.

By "trigger" I meant the condition(s) that cause(s) us to build that
list, and why these conditions happen so frequently.

> I can prepare exact play-by-play with code references, but that is
> going to take me some time.

Thanks, please take your time.  There's no rush.  I think we must have
a good understanding of what happens to discuss the potential
solutions and choose the best one.

> The gist of it is that we have tick-tock mechanism between NSApp and
> Emacs. When NSApp passes control to Emacs most of the allocations are
> dropped and when Emacs passes control to NSApp they are redone. This is
> by default unbounded, so when Emacs finishes processing events it
> immediatelly passes back to NSApp, which will pass back as soon as
> rendering is done.

OK, but I imagine we should be able to build this list in Emacs, when
needed, and then somehow let NSApp use it instead of re-creating it by
itself.  So if the problem is that NSApp needs this list, the question
I would be asking is why does it have to build it by itself instead of
using the list built by Emacs.  But I'm getting ahead of myself,
talking about issues I probably don't yet understand well enough.

Previous Next

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