bug#65908: 29.1.50; Emacs 29 regresses on macOS

[Eli Zaretskii]

> Date: Wed, 4 Oct 2023 22:16:22 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,
>       Gregory Heytings <gregory@heytings.org>, 65908@debbugs.gnu.org,
>       Eli Zaretskii <eliz@gnu.org>, ccsmile2008@outlook.com
> 
> On Wed, Oct 04, 2023 at 02:43:05PM +0200, Gerd Möllmann wrote:
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> > 
> > > Stefan Kangas <stefankangas@gmail.com> writes:
> > >
> > >>> I try to update the list of failing commits monthly.
> > >>
> > >> Thanks for maintaining that script.  We need more people showing that
> > >> kind of initiative and drive.
> > >
> > > +1
> > >
> > > And, three weeks later, the culprit is
> > >
> > > commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD)
> > > Author: Alan Third <alan@idiocy.org>
> > > Date:   Sun Nov 14 15:09:43 2021 +0000
> > >
> > >     Only set LANG if the ID is valid
> > >     
> > >     * src/nsterm.m (ns_init_locale): Check the provided locale identifier
> > >     is available before trying to use it.
> > >
> > > But don't ask me how that comes into play here because that function
> > > seems to be called from main only.  Maybe it's because LANG is now not
> > > always set, but used somewhere else?
> 
> AFAIK LANG isn't used by Emacs at all. That code is just there to help
> set up a default environment for running shell commands.
> 
> > As an experiment, I evaluated this in *scratch*:
> > 
> > (setenv "LANG" "")
> > (setenv "LC_COLLATE" "C")
> > (setenv "LC_CTYPE" "UTF-8")
> > (setenv "LC_MESSAGES" "C")
> > (setenv "LC_MONETARY" "C")
> > (setenv "LC_NUMERIC" "C")
> > (setenv "LC_TIME" "C")
> > 
> > which is the output of 'locale' in a terminal, translated to Elisp.
> > With these settings, the slowdown is gone, without changing the code.
> 
> So is Emacs run in the terminal with a LANG of something like
> en_GB.UTF-8 slower too? Because iirc my mac's terminal doesn't default
> to 'C' and I don't see anything GUI specific in the test code...
> 
> FWIW I don't see any meaningful difference using different locale
> settings on my Debian box, which makes me wonder if there is some
> low-level darwin code that reads the locale from the environment. Any
> idea if it's loading the files or stepping through the defuns that's
> slower, or both?
> 
> Long story short: I have no idea what's going on here.

Crystal ball says that the UTF-8 locale turns on some expensive
processing where it doesn't happen with the C locale.  One potential
place is case-insensitive comparisons and such likes.

Selectively setting only some of the LC_* variables limits the
expensive processing only to some operations.

In general, Emacs only needs to locale's settings to decide which
locale-environment and language-environment to turn on, all the rest
we do by ourselves.