* bug#65908: 29.1.50; Emacs 29 regresses on macOS
@ 2023-09-13 6:47 Zhang Haijun
2023-10-04 5:44 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Zhang Haijun @ 2023-09-13 6:47 UTC (permalink / raw)
To: 65908
[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]
1. emacs -Q
2. paste the following code to scratch buffer and execute it for saveral times
(benchmark-progn
(setq enable-dir-local-variables nil
enable-local-variables nil)
(let* ((test-dir "~/source/emacs-git/lisp")
(file-list (directory-files test-dir t
"\\`[fsw].*[.]el\\'" t))
(start-tm (current-time))
end-tm buf buf-list)
(dolist (test-file file-list)
(setq buf (find-file-noselect test-file))
(with-current-buffer buf
(goto-char (point-min))
(while (not (eobp))
(end-of-defun)))
(setq buf-list (cons buf buf-list)))
(setq end-tm (current-time))
(dolist (buf buf-list)
(kill-buffer buf))
(let ((delta (time-subtract end-tm start-tm)))
(message "--- files: %d, delta: %s"
(length file-list) (float-time delta)))))
======== Result for Emacs 27: ======
--- files: 61, delta: 3.021547
Elapsed time: 3.030485s (0.173305s in 14 GCs)
"--- files: 61, delta: 3.021547"
--- files: 61, delta: 3.1373
Elapsed time: 3.145406s (0.181551s in 14 GCs)
"--- files: 61, delta: 3.1373"
--- files: 61, delta: 3.093033
Elapsed time: 3.100581s (0.162783s in 13 GCs)
"--- files: 61, delta: 3.093033"
======== Result for Emacs 29: =======
--- files: 61, delta: 5.271817
Elapsed time: 5.278284s (0.174266s in 13 GCs)
"--- files: 61, delta: 5.271817"
--- files: 61, delta: 4.919798
Elapsed time: 4.923492s (0.162042s in 13 GCs)
"--- files: 61, delta: 4.919798"
--- files: 61, delta: 5.127965
Elapsed time: 5.131604s (0.154718s in 12 GCs)
"--- files: 61, delta: 5.127965"
--- files: 61, delta: 4.978964
Elapsed time: 4.982757s (0.149401s in 12 GCs)
"--- files: 61, delta: 4.978964"
Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2".
I also tested on Linux. There is no such big regress.
[-- Attachment #2: Type: text/html, Size: 6104 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-09-13 6:47 bug#65908: 29.1.50; Emacs 29 regresses on macOS Zhang Haijun
@ 2023-10-04 5:44 ` Gerd Möllmann
2023-10-04 7:38 ` Eli Zaretskii
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 5:44 UTC (permalink / raw)
To: Zhang Haijun; +Cc: 65908
Zhang Haijun <ccsmile2008@outlook.com> writes:
> 1 emacs -Q
> 2 paste the following code to scratch buffer and execute it for saveral times
>
> (benchmark-progn
> (setq enable-dir-local-variables nil
> enable-local-variables nil)
>
> (let* ((test-dir "~/source/emacs-git/lisp")
> (file-list (directory-files test-dir t
> "\\`[fsw].*[.]el\\'" t))
> (start-tm (current-time))
> end-tm buf buf-list)
>
> (dolist (test-file file-list)
> (setq buf (find-file-noselect test-file))
> (with-current-buffer buf
> (goto-char (point-min))
> (while (not (eobp))
> (end-of-defun)))
> (setq buf-list (cons buf buf-list)))
>
> (setq end-tm (current-time))
>
> (dolist (buf buf-list)
> (kill-buffer buf))
>
> (let ((delta (time-subtract end-tm start-tm)))
> (message "--- files: %d, delta: %s"
> (length file-list) (float-time delta)))))
(Your mailer does strange things with whitespace...)
> Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2".
> I also tested on Linux. There is no such big regress.
Thanks for the report.
I can reproduce this on macOS 14.0 (OCLP).
emacs-28, HEAD:
"--- files: 61, delta: 3.086468"
"--- files: 61, delta: 3.106478"
"--- files: 61, delta: 3.325344"
emacs-29, HEAD:
"--- files: 61, delta: 5.052421"
"--- files: 61, delta: 5.068663"
"--- files: 61, delta: 5.110502"
FWIW, master
"--- files: 61, delta: 5.124109"
"--- files: 61, delta: 5.101217"
"--- files: 61, delta: 5.13068"
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 5:44 ` Gerd Möllmann
@ 2023-10-04 7:38 ` Eli Zaretskii
2023-10-04 7:50 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-04 7:38 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 65908, ccsmile2008
> Cc: 65908@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Wed, 04 Oct 2023 07:44:33 +0200
>
> Zhang Haijun <ccsmile2008@outlook.com> writes:
>
> > 1 emacs -Q
> > 2 paste the following code to scratch buffer and execute it for saveral times
> >
> > (benchmark-progn
> > (setq enable-dir-local-variables nil
> > enable-local-variables nil)
> >
> > (let* ((test-dir "~/source/emacs-git/lisp")
> > (file-list (directory-files test-dir t
> > "\\`[fsw].*[.]el\\'" t))
> > (start-tm (current-time))
> > end-tm buf buf-list)
> >
> > (dolist (test-file file-list)
> > (setq buf (find-file-noselect test-file))
> > (with-current-buffer buf
> > (goto-char (point-min))
> > (while (not (eobp))
> > (end-of-defun)))
> > (setq buf-list (cons buf buf-list)))
> >
> > (setq end-tm (current-time))
> >
> > (dolist (buf buf-list)
> > (kill-buffer buf))
> >
> > (let ((delta (time-subtract end-tm start-tm)))
> > (message "--- files: %d, delta: %s"
> > (length file-list) (float-time delta)))))
>
> (Your mailer does strange things with whitespace...)
>
> > Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2".
> > I also tested on Linux. There is no such big regress.
>
> Thanks for the report.
>
> I can reproduce this on macOS 14.0 (OCLP).
>
> emacs-28, HEAD:
> "--- files: 61, delta: 3.086468"
> "--- files: 61, delta: 3.106478"
> "--- files: 61, delta: 3.325344"
>
> emacs-29, HEAD:
> "--- files: 61, delta: 5.052421"
> "--- files: 61, delta: 5.068663"
> "--- files: 61, delta: 5.110502"
>
> FWIW, master
> "--- files: 61, delta: 5.124109"
> "--- files: 61, delta: 5.101217"
> "--- files: 61, delta: 5.13068"
A completely expanded Lisp profile, after loading the Lisp files
involved in this as *.el, would be appreciated.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 7:38 ` Eli Zaretskii
@ 2023-10-04 7:50 ` Gerd Möllmann
2023-10-04 8:29 ` Stefan Kangas
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 7:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 65908, ccsmile2008
On 04.10.23 09:38, Eli Zaretskii wrote:
>> Cc: 65908@debbugs.gnu.org
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Wed, 04 Oct 2023 07:44:33 +0200
>>
>> Zhang Haijun <ccsmile2008@outlook.com> writes:
>>
>>> 1 emacs -Q
>>> 2 paste the following code to scratch buffer and execute it for saveral times
>>>
>>> (benchmark-progn
>>> (setq enable-dir-local-variables nil
>>> enable-local-variables nil)
>>>
>>> (let* ((test-dir "~/source/emacs-git/lisp")
>>> (file-list (directory-files test-dir t
>>> "\\`[fsw].*[.]el\\'" t))
>>> (start-tm (current-time))
>>> end-tm buf buf-list)
>>>
>>> (dolist (test-file file-list)
>>> (setq buf (find-file-noselect test-file))
>>> (with-current-buffer buf
>>> (goto-char (point-min))
>>> (while (not (eobp))
>>> (end-of-defun)))
>>> (setq buf-list (cons buf buf-list)))
>>>
>>> (setq end-tm (current-time))
>>>
>>> (dolist (buf buf-list)
>>> (kill-buffer buf))
>>>
>>> (let ((delta (time-subtract end-tm start-tm)))
>>> (message "--- files: %d, delta: %s"
>>> (length file-list) (float-time delta)))))
>>
>> (Your mailer does strange things with whitespace...)
>>
>>> Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2".
>>> I also tested on Linux. There is no such big regress.
>>
>> Thanks for the report.
>>
>> I can reproduce this on macOS 14.0 (OCLP).
>>
>> emacs-28, HEAD:
>> "--- files: 61, delta: 3.086468"
>> "--- files: 61, delta: 3.106478"
>> "--- files: 61, delta: 3.325344"
>>
>> emacs-29, HEAD:
>> "--- files: 61, delta: 5.052421"
>> "--- files: 61, delta: 5.068663"
>> "--- files: 61, delta: 5.110502"
>>
>> FWIW, master
>> "--- files: 61, delta: 5.124109"
>> "--- files: 61, delta: 5.101217"
>> "--- files: 61, delta: 5.13068"
>
> A completely expanded Lisp profile, after loading the Lisp files
> involved in this as *.el, would be appreciated.
I'm trying to bisect this, which turns out to be a bit tedious because
many commits on emacs-29 don't build. I'll come back when I have something.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 7:50 ` Gerd Möllmann
@ 2023-10-04 8:29 ` Stefan Kangas
2023-10-04 8:32 ` Gerd Möllmann
2023-10-04 9:02 ` Gregory Heytings
0 siblings, 2 replies; 45+ messages in thread
From: Stefan Kangas @ 2023-10-04 8:29 UTC (permalink / raw)
To: Gerd Möllmann, Eli Zaretskii; +Cc: Gregory Heytings, 65908, ccsmile2008
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> I'm trying to bisect this, which turns out to be a bit tedious because
> many commits on emacs-29 don't build. I'll come back when I have something.
Does the script admin/git-bisect-start help?
Gregory will correct me if I'm wrong, but I think it's okay to add any
commits that don't build to the list there.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 8:29 ` Stefan Kangas
@ 2023-10-04 8:32 ` Gerd Möllmann
2023-10-04 9:02 ` Gregory Heytings
1 sibling, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 8:32 UTC (permalink / raw)
To: Stefan Kangas, Eli Zaretskii; +Cc: Gregory Heytings, 65908, ccsmile2008
On 04.10.23 10:29, Stefan Kangas wrote:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> I'm trying to bisect this, which turns out to be a bit tedious because
>> many commits on emacs-29 don't build. I'll come back when I have something.
>
> Does the script admin/git-bisect-start help?
Yes it helps. Gregory set me on the right path already. I had
completely forgotten.
>
> Gregory will correct me if I'm wrong, but I think it's okay to add any
> commits that don't build to the list there.
If that's okay, I already have one I could add.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 8:29 ` Stefan Kangas
2023-10-04 8:32 ` Gerd Möllmann
@ 2023-10-04 9:02 ` Gregory Heytings
2023-10-04 9:12 ` Gerd Möllmann
2023-10-04 9:12 ` Stefan Kangas
1 sibling, 2 replies; 45+ messages in thread
From: Gregory Heytings @ 2023-10-04 9:02 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008
>
> Gregory will correct me if I'm wrong, but I think it's okay to add any
> commits that don't build to the list there.
>
It's okay in principle, but the idea of that script is to include only
commits that don't build on GNU/Linux, with GCC, and with the default
build options (just "make"). I try to update the list of failing commits
monthly.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 9:02 ` Gregory Heytings
@ 2023-10-04 9:12 ` Gerd Möllmann
2023-10-04 9:12 ` Stefan Kangas
1 sibling, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 9:12 UTC (permalink / raw)
To: Gregory Heytings, Stefan Kangas; +Cc: Eli Zaretskii, 65908, ccsmile2008
On 04.10.23 11:02, Gregory Heytings wrote:
>
>>
>> Gregory will correct me if I'm wrong, but I think it's okay to add any
>> commits that don't build to the list there.
>>
>
> It's okay in principle, but the idea of that script is to include only
> commits that don't build on GNU/Linux, with GCC, and with the default
> build options (just "make"). I try to update the list of failing
> commits monthly.
>
That's okay, I can roll my own.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 9:02 ` Gregory Heytings
2023-10-04 9:12 ` Gerd Möllmann
@ 2023-10-04 9:12 ` Stefan Kangas
2023-10-04 10:55 ` Gerd Möllmann
2023-10-05 8:58 ` Gregory Heytings
1 sibling, 2 replies; 45+ messages in thread
From: Stefan Kangas @ 2023-10-04 9:12 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008
Gregory Heytings <gregory@heytings.org> writes:
>> Gregory will correct me if I'm wrong, but I think it's okay to add any
>> commits that don't build to the list there.
>
> It's okay in principle, but the idea of that script is to include only
> commits that don't build on GNU/Linux, with GCC, and with the default
> build options (just "make").
Thanks, I now see that explained a bit further down in the file.
Perhaps that explanation could be moved to the very top of the file?
> 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.
BTW, if you have any scripts that you use to update the list, it might
be useful to add them to emacs.git. Perhaps just as a comment to
git-bisect-start, depending on how long it is. That would decrease the
bus factor.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 9:12 ` Stefan Kangas
@ 2023-10-04 10:55 ` Gerd Möllmann
2023-10-04 12:43 ` Gerd Möllmann
2023-10-05 8:58 ` Gregory Heytings
1 sibling, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 10:55 UTC (permalink / raw)
To: Stefan Kangas
Cc: Gregory Heytings, 65908, Eli Zaretskii, Alan Third, ccsmile2008
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?
Added Alan Third to the CC.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 10:55 ` Gerd Möllmann
@ 2023-10-04 12:43 ` Gerd Möllmann
2023-10-04 21:16 ` Alan Third
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-04 12:43 UTC (permalink / raw)
To: Stefan Kangas
Cc: ccsmile2008, Gregory Heytings, 65908, Eli Zaretskii, Alan Third
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?
>
> Added Alan Third to the CC.
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 12:43 ` Gerd Möllmann
@ 2023-10-04 21:16 ` Alan Third
2023-10-05 5:41 ` Eli Zaretskii
2023-10-05 5:55 ` Gerd Möllmann
0 siblings, 2 replies; 45+ messages in thread
From: Alan Third @ 2023-10-04 21:16 UTC (permalink / raw)
To: Gerd Möllmann
Cc: Gregory Heytings, 65908, Eli Zaretskii, Stefan Kangas,
ccsmile2008
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.
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 21:16 ` Alan Third
@ 2023-10-05 5:41 ` Eli Zaretskii
2023-10-05 5:55 ` Gerd Möllmann
1 sibling, 0 replies; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 5:41 UTC (permalink / raw)
To: Alan Third; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008
> 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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 21:16 ` Alan Third
2023-10-05 5:41 ` Eli Zaretskii
@ 2023-10-05 5:55 ` Gerd Möllmann
2023-10-05 6:08 ` Eli Zaretskii
1 sibling, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 5:55 UTC (permalink / raw)
To: Alan Third
Cc: Gregory Heytings, 65908, Eli Zaretskii, Stefan Kangas,
ccsmile2008
Alan Third <alan@idiocy.org> writes:
>> 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.
Me neither. I tried to find something definitive about locales+bundles
Apple's docs, and on the Internet in general, but failed miserably.
What a mess.
Anyway, something is odd here, I think.
When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking
Emacs.app, then M-x shell, I get
$ locale
LANG=""
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
That can't be right, or is it?
The same, one commit before that:
$ locale
LANG="en_DE.UTF-8"
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
At least LANG looks correct to me (I'm using an English UI, in DE.).
The LC_* are odd, though.
As an aside - vscode sets all of these vars to "en_US.UTF-8" which is
looks wrong, and the Zed editor does the same, except for LANG which it
set to "".
I must admit that I can't come to a conclusion here. Maybe the right
thing would be LANG="en_DE.UTF-8" plus setting LC_ALL=$LANG like vscode?
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 5:55 ` Gerd Möllmann
@ 2023-10-05 6:08 ` Eli Zaretskii
2023-10-05 8:52 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 6:08 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: alan, gregory, 65908, stefankangas, ccsmile2008
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Gregory Heytings
> <gregory@heytings.org>, 65908@debbugs.gnu.org, Eli Zaretskii
> <eliz@gnu.org>, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 07:55:55 +0200
>
> When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking
> Emacs.app, then M-x shell, I get
>
> $ locale
> LANG=""
> LC_COLLATE="C"
> LC_CTYPE="C"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL=
>
> That can't be right, or is it?
>
> The same, one commit before that:
>
> $ locale
> LANG="en_DE.UTF-8"
> LC_COLLATE="C"
> LC_CTYPE="C"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL=
>
> At least LANG looks correct to me (I'm using an English UI, in DE.).
> The LC_* are odd, though.
Emacs forces LC_ALL= and LC_NUMERIC=C, to properly localize the
initial error messages and format numbers as in the "C" locale, see
'main' (which also has an NS-specific code).
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 6:08 ` Eli Zaretskii
@ 2023-10-05 8:52 ` Gerd Möllmann
2023-10-05 9:48 ` Alan Third
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 8:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: alan, gregory, 65908, stefankangas, ccsmile2008
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, Gregory Heytings
>> <gregory@heytings.org>, 65908@debbugs.gnu.org, Eli Zaretskii
>> <eliz@gnu.org>, ccsmile2008@outlook.com
>> Date: Thu, 05 Oct 2023 07:55:55 +0200
>>
>> When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking
>> Emacs.app, then M-x shell, I get
>>
>> $ locale
>> LANG=""
>> LC_COLLATE="C"
>> LC_CTYPE="C"
>> LC_MESSAGES="C"
>> LC_MONETARY="C"
>> LC_NUMERIC="C"
>> LC_TIME="C"
>> LC_ALL=
>>
>> That can't be right, or is it?
>>
>> The same, one commit before that:
>>
>> $ locale
>> LANG="en_DE.UTF-8"
>> LC_COLLATE="C"
>> LC_CTYPE="C"
>> LC_MESSAGES="C"
>> LC_MONETARY="C"
>> LC_NUMERIC="C"
>> LC_TIME="C"
>> LC_ALL=
>>
>> At least LANG looks correct to me (I'm using an English UI, in DE.).
>> The LC_* are odd, though.
>
> Emacs forces LC_ALL= and LC_NUMERIC=C, to properly localize the
> initial error messages and format numbers as in the "C" locale, see
> 'main' (which also has an NS-specific code).
Thanks for the hint, Eli.
I've meanwhile found out something. Not yet sure what to make of this,
but anyway:
1. In ns_init_locale, [locale localeIdentifier] returns "en_DE" on my
system, which is, I think, a consequence of my system settings, as I
mentioned (English UI in Germany).
2. man setlocale(3) says this
An argument of "" will
determine the name of the new locale taking into account the environment
variables LANG and LC_*.
So, the setlocale (LC_ALL, "") in main should initialize LC_* according
to LANG, if set. (Another question might be if that is what was
intended here, when I read the comment above that code, but be that as
it may.)
And another thing - any setlocale in ns_init_locale is moot because it
will be undone in main.
4. When I setenv LANG="en_DE.UTF-8" in ns_init_locale, the setlocale
(LC_ALL, "") returns NULL, indicating that LANG is invalid. And, indeed
$ locale -a | grep de
de_CH
de_DE.UTF-8
de_AT.ISO8859-1
de_AT.UTF-8
de_AT.ISO8859-15
de_DE.ISO8859-15
de_CH.UTF-8
de_CH.ISO8859-15
de_DE.ISO8859-1
de_CH.ISO8859-1
de_AT
de_DE
There is no en_DE...
5. When I don't use localeIndentifier, but "en_US.UTF-8", for instance,
the setlocale (LC_ALL, "") in main works like expected, and in a shell
buffer:
$ ~/emacs/master/src/ > locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
That's all not very nice :-).
Conclusion so far, for me,
- don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE,
maybe.
- localeIndentifier is wrong for mixed cases like "en_DE".
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-04 9:12 ` Stefan Kangas
2023-10-04 10:55 ` Gerd Möllmann
@ 2023-10-05 8:58 ` Gregory Heytings
2023-10-05 9:03 ` Gregory Heytings
1 sibling, 1 reply; 45+ messages in thread
From: Gregory Heytings @ 2023-10-05 8:58 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008
>> It's okay in principle, but the idea of that script is to include only
>> commits that don't build on GNU/Linux, with GCC, and with the default
>> build options (just "make").
>
> Thanks, I now see that explained a bit further down in the file.
>
> Perhaps that explanation could be moved to the very top of the file?
>
Done (cfcdb6ec2a).
>
> BTW, if you have any scripts that you use to update the list, it might
> be useful to add them to emacs.git. Perhaps just as a comment to
> git-bisect-start, depending on how long it is. That would decrease the
> bus factor.
>
These scripts are almost trivial: for each not yet checked commit, do git
checkout, make, and check the result. The only slightly complex part is
"for each not yet checked commit": it uses the list of all commits that I
already checked (currently 21484, in a 860 KB text file), and I'm not sure
adding that big file to emacs.git would be appropriate.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 8:58 ` Gregory Heytings
@ 2023-10-05 9:03 ` Gregory Heytings
0 siblings, 0 replies; 45+ messages in thread
From: Gregory Heytings @ 2023-10-05 9:03 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008
>
> it uses the list of all commits that I already checked (currently 21484,
> in a 860 KB text file)
>
Sorry: (currently 39928, in 1.9 MB text file).
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 8:52 ` Gerd Möllmann
@ 2023-10-05 9:48 ` Alan Third
2023-10-05 11:12 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Alan Third @ 2023-10-05 9:48 UTC (permalink / raw)
To: Gerd Möllmann
Cc: Eli Zaretskii, gregory, 65908, stefankangas, ccsmile2008
On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote:
> Conclusion so far, for me,
>
> - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE,
> maybe.
setlocale in ns_init_locale is only there to check if the locale is
valid, it resets it back to its initial value at the end.
> - localeIndentifier is wrong for mixed cases like "en_DE".
There was some trouble with warning messages in the terminal when
using an invalid locale ID (see bug#51321), but that may only be
because Daniel had changed the code to set LC_ALL instead of LANG.
I preferred setting LANG anyway because it acts as a fallback, and
this is pretty much intended as a fallback, anything else explicitly
set will override it.
Out of interest, when is it slow? Is it when we have an invalid locale
ID?
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 9:48 ` Alan Third
@ 2023-10-05 11:12 ` Gerd Möllmann
2023-10-05 13:18 ` Gerd Möllmann
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 11:12 UTC (permalink / raw)
To: Alan Third; +Cc: Eli Zaretskii, gregory, 65908, stefankangas, ccsmile2008
Alan Third <alan@idiocy.org> writes:
> On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote:
>> Conclusion so far, for me,
>>
>> - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE,
>> maybe.
>
> setlocale in ns_init_locale is only there to check if the locale is
> valid, it resets it back to its initial value at the end.
That's okay. What I meant was setting the old locale at the end.
>> - localeIndentifier is wrong for mixed cases like "en_DE".
>
> There was some trouble with warning messages in the terminal when
> using an invalid locale ID (see bug#51321), but that may only be
> because Daniel had changed the code to set LC_ALL instead of LANG.
Thanks, I'll take a look.
>
> I preferred setting LANG anyway because it acts as a fallback, and
> this is pretty much intended as a fallback, anything else explicitly
> set will override it.
I think that's TRT, indeed.
>
> Out of interest, when is it slow? Is it when we have an invalid locale
> ID?
That's an interesting question--whatever I do on master, it's almost
equally slow :-).
It would be nice if I could get at least the right character encoding on
my system... On the plus side, I at least know now what's happening,
although I don't know what to do.
BTW, @ccsmile: What are your locale settings?
Aprt from that, I'm currently trying to get profiling working on my old
Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which
show the difference. That could maybe answer your question.
Buhut... I can't currently get Instruments to work, which might be
related to the fact that I've updated my unsupported by Apple Macbook to
Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for
my display arrives soon, so that I can use my Mac mini again. A lot of
construction sites ahead :-).
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 11:12 ` Gerd Möllmann
@ 2023-10-05 13:18 ` Gerd Möllmann
2023-10-05 16:11 ` Eli Zaretskii
2023-10-05 13:51 ` Alan Third
2023-10-05 13:56 ` Gerd Möllmann
2 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 13:18 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> It would be nice if I could get at least the right character encoding on
> my system... On the plus side, I at least know now what's happening,
> although I don't know what to do.
I'd like to propose the attached patch for problem of invalid LANG
setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
or something valid can't be deduced from the locale.
I find this acceptable even in my setting ("en_DE") because even Apple's
Terminal doesn't get this right. A closer looks at what is set in the
locale in Terminal shows that, for instance, date format and thousands
separator are en_US anyway.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ns_init_locale --]
[-- Type: text/x-patch, Size: 2370 bytes --]
From 93457632cd5f17de01ec291d888d2d2fb0acffdf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Thu, 5 Oct 2023 15:12:40 +0200
Subject: [PATCH] Handle LANG on macOS differntly (bug#bug#65908)
* src/nsterm.m (ns_init_locale): If LANG is set, try to use that,
otherwise try to deduce what LANG should be. Check is the result is
valid, and use LANG="en_US.UTF-8" if not.
---
src/nsterm.m | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/src/nsterm.m b/src/nsterm.m
index 4e0dfa58c63..09cb7236b6e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -554,29 +554,25 @@ - (unsigned long)unsignedLong
/* macOS doesn't set any environment variables for the locale when run
from the GUI. Get the locale from the OS and set LANG. */
{
- NSLocale *locale = [NSLocale currentLocale];
-
NSTRACE ("ns_init_locale");
- /* If we were run from a terminal then assume an unset LANG variable
- is intentional and don't try to "fix" it. */
- if (!isatty (STDIN_FILENO))
+ const char *lang = getenv ("LANG");
+ if (lang == NULL)
{
- char *oldLocale = setlocale (LC_ALL, NULL);
- /* It seems macOS should probably use UTF-8 everywhere.
- 'localeIdentifier' does not specify the encoding, and I can't
- find any way to get the OS to tell us which encoding to use,
- so hard-code '.UTF-8'. */
- NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
- [locale localeIdentifier]];
+ const NSLocale *locale = [NSLocale currentLocale];
+ const NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
+ [locale localeIdentifier]];
+ lang = [localeID UTF8String];
+ }
- /* Check the locale ID is valid and if so set LANG, but not if
- it is already set. */
- if (setlocale (LC_ALL, [localeID UTF8String]))
- setenv("LANG", [localeID UTF8String], 0);
+ /* Check if LANG can be used for initializing the locale. If not,
+ use a default setting. Note that Emacs' main will undo the
+ setlocale below, initializing the locale from the
+ environment. */
+ if (setlocale (LC_ALL, lang) == NULL)
+ lang = "en_US.UTF-8";
- setlocale (LC_ALL, oldLocale);
- }
+ setenv ("LANG", lang, 1);
}
--
2.39.3 (Apple Git-145)
^ permalink raw reply related [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 11:12 ` Gerd Möllmann
2023-10-05 13:18 ` Gerd Möllmann
@ 2023-10-05 13:51 ` Alan Third
2023-10-05 14:01 ` Gerd Möllmann
2023-10-05 14:09 ` Gerd Möllmann
2023-10-05 13:56 ` Gerd Möllmann
2 siblings, 2 replies; 45+ messages in thread
From: Alan Third @ 2023-10-05 13:51 UTC (permalink / raw)
To: Gerd Möllmann
Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
On Thu, Oct 05, 2023 at 01:12:10PM +0200, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
>
> > On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote:
> >> Conclusion so far, for me,
> >>
> >> - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE,
> >> maybe.
> >
> > setlocale in ns_init_locale is only there to check if the locale is
> > valid, it resets it back to its initial value at the end.
>
> That's okay. What I meant was setting the old locale at the end.
I've managed to reproduce this, and the time difference on my machine
is ridiculous. From 4 seconds without the setlocale calls to 24
seconds with.
And that's with a legitimate, installed, locale ID in both cases.
I wonder if this is why some people report Emacs 29 on macOS to be
noticeably slower. They, of course, blame the graphics changes, but
with that sort of variation in time...
> > Out of interest, when is it slow? Is it when we have an invalid locale
> > ID?
>
> That's an interesting question--whatever I do on master, it's almost
> equally slow :-).
>
> It would be nice if I could get at least the right character encoding on
> my system... On the plus side, I at least know now what's happening,
> although I don't know what to do.
Indeed. I'm tempted to say we should revert the change since I now
suspect I misunderstood how setlocale works when I wrote this and I'm
not sure it's actually improving anything.
OTOH, it would be good if we could get this to actually work and
generate correct locale ID's for the system... But then, I don't know
what *is* a correct locale ID for a system like yours...
> Aprt from that, I'm currently trying to get profiling working on my old
> Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which
> show the difference. That could maybe answer your question.
>
> Buhut... I can't currently get Instruments to work, which might be
> related to the fact that I've updated my unsupported by Apple Macbook to
> Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for
> my display arrives soon, so that I can use my Mac mini again. A lot of
> construction sites ahead :-).
I couldn't even get the old commit to build, I had to use the current
master and just revert to see the difference. So best of luck! :)
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 11:12 ` Gerd Möllmann
2023-10-05 13:18 ` Gerd Möllmann
2023-10-05 13:51 ` Alan Third
@ 2023-10-05 13:56 ` Gerd Möllmann
2023-10-05 16:19 ` Eli Zaretskii
2 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 13:56 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Aprt from that, I'm currently trying to get profiling working on my old
> Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which
> show the difference. That could maybe answer your question.
To the question of profiling. I've now used the built-in profiler on
the two commits, but I must say that I don't see where the difference
comes from. These are debug builds, 5 runs of the benchmark.
[-- Attachment #2: slow case --]
[-- Type: text/plain, Size: 18160 bytes --]
6446 92% - command-execute
6446 92% - call-interactively
6287 90% - funcall-interactively
6268 89% - eval-print-last-sexp
6268 89% - eval-last-sexp
6268 89% - elisp--eval-last-sexp
6264 89% - eval
6264 89% - progn
6264 89% - let
6257 89% - progn
6257 89% - let*
6247 89% - let
6247 89% - while
6247 89% - let
3680 52% - save-current-buffer
3678 52% - while
3662 52% - end-of-defun
2494 35% - beginning-of-defun-raw
2392 34% - syntax-ppss
1 0% #<compiled 0x8a30a7d371919be>
1107 15% - #<compiled 0x1f5ce039ca16>
1084 15% forward-sexp
7 0% #<compiled -0x1367a2fd14e17470>
1 0% not
2553 36% - setq
2553 36% - find-file-noselect
1962 28% - find-file-noselect-1
1583 22% - after-find-file
1493 21% - run-hooks
1493 21% - vc-refresh-state
650 9% - vc-backend
650 9% - vc-registered
648 9% - mapc
648 9% - #<compiled 0x97a1a3d44aacb78>
648 9% - vc-call-backend
648 9% - apply
340 4% - vc-git-registered
157 2% - cd
151 2% - locate-file
150 2% - locate-file-internal
150 2% #<compiled -0x52006ec4d330c6b>
6 0% cd-absolute
77 1% file-relative-name
59 0% - vc-git--out-ok
59 0% - apply
59 0% - vc-git--call
59 0% - apply
59 0% - process-file
59 0% - apply
1 0% call-process
28 0% - vc-git-root
28 0% - vc-find-root
28 0% - locate-dominating-file
1 0% abbreviate-file-name
19 0% - if
19 0% - progn
16 0% - load
10 0% - require
3 0% - byte-code
2 0% require
1 0% - byte-code
1 0% require
2 0% - vc-git-registered
1 0% - vc-git-root
1 0% - vc-find-root
1 0% - locate-dominating-file
1 0% abbreviate-file-name
1 0% - vc-git--out-ok
1 0% - apply
1 0% - vc-git--call
1 0% - apply
1 0% - process-file
1 0% apply
252 3% - vc-rcs-registered
252 3% - vc-default-registered
252 3% - vc-check-master-templates
252 3% - mapcar
252 3% #<compiled -0x14b119dcda574f9a>
24 0% - vc-bzr-registered
24 0% - if
24 0% - vc-find-root
24 0% - locate-dominating-file
2 0% abbreviate-file-name
17 0% - vc-svn-registered
17 0% - let
17 0% - if
17 0% - vc-find-root
17 0% - locate-dominating-file
6 0% abbreviate-file-name
6 0% - vc-cvs-registered
6 0% if
3 0% - vc-src-registered
3 0% - vc-default-registered
3 0% - vc-check-master-templates
3 0% - mapcar
3 0% #<compiled 0x9df477c7900869f>
3 0% - vc-mtn-registered
3 0% - if
3 0% - vc-find-root
3 0% - locate-dominating-file
1 0% abbreviate-file-name
2 0% - vc-sccs-registered
2 0% - vc-default-registered
2 0% - vc-check-master-templates
2 0% - mapcar
2 0% #<compiled -0x162bb36be296685a>
1 0% - vc-hg-registered
1 0% - if
1 0% - vc-find-root
1 0% locate-dominating-file
1 0% vc-file-getprop
556 7% - vc-mode-line
358 5% - vc-call-backend
358 5% - apply
358 5% - vc-git-mode-line-string
264 3% - vc-working-revision
264 3% - vc-call-backend
264 3% - apply
264 3% - vc-git-working-revision
264 3% - vc-git--rev-parse
264 3% - vc-git--out-ok
264 3% - apply
264 3% - vc-git--call
264 3% - apply
264 3% - process-file
264 3% apply
94 1% - vc-git--symbolic-ref
93 1% - vc-git--run-command-string
93 1% - apply
93 1% - vc-git--out-ok
93 1% - apply
93 1% - vc-git--call
93 1% - apply
93 1% - process-file
93 1% apply
286 4% - vc-call-backend
286 4% - apply
286 4% - vc-git-find-file-hook
286 4% - vc-state
286 4% - vc-state-refresh
286 4% - vc-call-backend
286 4% - apply
286 4% - vc-git-state
286 4% - apply
286 4% - vc-git--run-command-string
167 2% file-relative-name
118 1% - apply
118 1% - vc-git--out-ok
118 1% - apply
116 1% - vc-git--call
116 1% - apply
112 1% - process-file
112 1% apply
1 0% generate-new-buffer
1 0% vc-file-clearprops
62 0% - normal-mode
60 0% - set-auto-mode
60 0% - set-auto-mode--apply-alist
27 0% - set-auto-mode-0
27 0% - emacs-lisp-mode
24 0% - run-mode-hooks
16 0% - hack-local-variables
12 0% - hack-local-variables-prop-line
11 0% - set-auto-mode-1
11 0% - inhibit-local-variables-p
1 0% file-name-sans-versions
2 0% - hack-local-variables--find-variables
1 0% - #<compiled -0x1c1d2016f82fdd9b>
1 0% kill-buffer
8 0% - run-hooks
7 0% - global-font-lock-mode-enable-in-buffers
6 0% - turn-on-font-lock-if-desired
6 0% - turn-on-font-lock
6 0% - font-lock-mode
6 0% - font-lock-default-function
6 0% - font-lock-mode-internal
5 0% - font-lock-turn-on-thing-lock
3 0% - jit-lock-register
3 0% - jit-lock-mode
1 0% jit-lock-refontify
1 0% remove-hook
1 0% - font-lock-set-defaults
1 0% - font-lock-add-keywords
1 0% font-lock-remove-keywords
1 0% - global-eldoc-mode-enable-in-buffers
1 0% - turn-on-eldoc-mode
1 0% - eldoc-mode
1 0% run-hooks
2 0% - lisp-data-mode
2 0% - prog-mode
1 0% - kill-all-local-variables
1 0% global-eldoc-mode-cmhh
8 0% assoc-default
2 0% - font-lock-mode
2 0% - font-lock-default-function
2 0% - font-lock-mode-internal
2 0% - font-lock-turn-on-thing-lock
1 0% - jit-lock-register
1 0% - jit-lock-mode
1 0% jit-lock-refontify
67 0% - file-truename
57 0% - file-truename
50 0% - file-truename
35 0% - file-truename
20 0% - file-truename
10 0% file-truename
11 0% - insert-file-contents
11 0% - set-auto-coding
11 0% - find-auto-coding
10 0% auto-coding-alist-lookup
5 0% abbreviate-file-name
286 4% - find-buffer-visiting
23 0% - file-truename
18 0% - file-truename
11 0% - file-truename
10 0% - file-truename
7 0% - file-truename
2 0% file-truename
3 0% abbreviate-file-name
254 3% abbreviate-file-name
28 0% - file-truename
15 0% - file-truename
12 0% - file-truename
7 0% - file-truename
5 0% - file-truename
3 0% file-truename
4 0% - create-file-buffer
4 0% - apply
4 0% - uniquify--create-file-buffer-advice
3 0% - uniquify-rationalize-file-buffer-names
1 0% - uniquify-rationalize
1 0% uniquify-rationalize-a-list
7 0% - message
7 0% - float-time
3 0% - time-since
3 0% - byte-code
1 0% require
1 0% - elisp--preceding-sexp
1 0% forward-sexp
7 0% - previous-line
7 0% - line-move
4 0% line-move-visual
7 0% - execute-extended-command
7 0% - command-execute
7 0% - call-interactively
7 0% - funcall-interactively
7 0% profiler-report
4 0% - next-line
4 0% - line-move
2 0% line-move-visual
1 0% - default-line-height
1 0% default-font-height
1 0% - move-end-of-line
1 0% - line-move
1 0% line-move-1
159 2% - byte-code
159 2% - read-extended-command
159 2% - completing-read
159 2% - completing-read-default
36 0% - read-from-minibuffer
15 0% - command-execute
15 0% - call-interactively
15 0% - funcall-interactively
15 0% - minibuffer-complete
15 0% - completion-in-region
15 0% - completion--in-region
15 0% - #<compiled -0x1b9ffa9feb95062>
15 0% - apply
15 0% - #<compiled 0xdedd3f31b64fd0>
15 0% - completion--in-region-1
15 0% - completion--do-completion
7 0% - completion-try-completion
7 0% - completion--nth-completion
7 0% - completion--some
7 0% - #<compiled 0x1b6e37e38eac17b5>
7 0% - completion-basic-try-completion
7 0% - try-completion
7 0% - #<compiled 0x523b6c540a44927>
7 0% complete-with-action
7 0% - minibuffer-completion-help
4 0% - temp-buffer-window-show
4 0% - display-buffer
4 0% - display-buffer-at-bottom
3 0% - window--display-buffer
2 0% fit-window-to-buffer
1 0% - #<compiled -0x189b606b4eedbb15>
1 0% - display-completion-list
1 0% - run-hooks
1 0% - completion-setup-function
1 0% substitute-command-keys
1 0% - walk-window-tree
1 0% - walk-window-tree-1
1 0% - #<compiled -0xc246f5dbd4eb22b>
1 0% window-in-direction
3 0% - completion-all-completions
3 0% - completion--nth-completion
3 0% - completion--some
3 0% - #<compiled 0xaf1c20e12870063>
3 0% - completion-basic-all-completions
3 0% - completion-pcm--all-completions
3 0% - all-completions
3 0% - #<compiled 0x523b6c540a44927>
3 0% complete-with-action
1 0% - minibuffer-hide-completions
1 0% - bury-buffer
1 0% - window--delete
1 0% delete-window
522 7% + ...
12 0% + timer-event-handler
5 0% + redisplay_internal (C function)
[-- Attachment #3: fast case --]
[-- Type: text/plain, Size: 16803 bytes --]
6199 91% - command-execute
6199 91% - call-interactively
6066 89% - funcall-interactively
6040 88% - eval-print-last-sexp
6040 88% - eval-last-sexp
6040 88% - elisp--eval-last-sexp
6034 88% - eval
6034 88% - progn
6034 88% - let
6028 88% - progn
6028 88% - let*
6016 88% - let
6016 88% - while
6016 88% - let
3547 52% - save-current-buffer
3546 52% - while
3539 52% - end-of-defun
2440 35% - beginning-of-defun-raw
2334 34% - syntax-ppss
1 0% #<compiled 0x8a3336d7832903e>
1033 15% - #<compiled 0x1f5ce1910a16>
1009 14% forward-sexp
5 0% #<compiled -0x1367a2fddcb57470>
2453 36% - setq
2453 36% - find-file-noselect
1864 27% - find-file-noselect-1
1486 21% - after-find-file
1396 20% - run-hooks
1396 20% - vc-refresh-state
640 9% - vc-backend
640 9% - vc-registered
638 9% - mapc
638 9% - #<compiled 0x97a6b2bf5b90b78>
638 9% - vc-call-backend
638 9% - apply
338 4% - vc-git-registered
168 2% - cd
165 2% - locate-file
164 2% - locate-file-internal
164 2% #<compiled -0x52006ec4d330c6b>
3 0% cd-absolute
68 1% file-relative-name
49 0% - vc-git--out-ok
49 0% - apply
49 0% - vc-git--call
49 0% - apply
49 0% - process-file
49 0% apply
33 0% - vc-git-root
33 0% - vc-find-root
33 0% - locate-dominating-file
2 0% abbreviate-file-name
18 0% - if
18 0% - progn
17 0% - load
9 0% - require
4 0% - byte-code
2 0% require
1 0% - byte-code
1 0% require
1 0% - vc-git-registered
1 0% - vc-git--out-ok
1 0% - apply
1 0% - vc-git--call
1 0% - apply
1 0% - process-file
1 0% apply
1 0% - #<compiled -0x1c1ed57c55005f9b>
1 0% kill-buffer
257 3% - vc-rcs-registered
257 3% - vc-default-registered
256 3% - vc-check-master-templates
256 3% - mapcar
256 3% #<compiled -0x117f5e38d4b1020e>
19 0% - vc-svn-registered
19 0% - let
19 0% - if
19 0% - vc-find-root
19 0% - locate-dominating-file
8 0% abbreviate-file-name
11 0% - vc-bzr-registered
11 0% - if
11 0% - vc-find-root
11 0% locate-dominating-file
5 0% - vc-sccs-registered
5 0% - vc-default-registered
5 0% - vc-check-master-templates
5 0% - mapcar
5 0% #<compiled 0xc73f4e04c5b42f1>
4 0% - vc-src-registered
4 0% - vc-default-registered
4 0% - vc-check-master-templates
4 0% - mapcar
4 0% #<compiled -0x1827ab73baee87a5>
2 0% - vc-mtn-registered
2 0% - if
2 0% - vc-find-root
2 0% locate-dominating-file
1 0% - vc-cvs-registered
1 0% if
1 0% - vc-hg-registered
1 0% - if
1 0% - vc-find-root
1 0% locate-dominating-file
472 6% - vc-mode-line
338 4% - vc-call-backend
338 4% - apply
338 4% - vc-git-mode-line-string
281 4% - vc-working-revision
281 4% - vc-call-backend
281 4% - apply
281 4% - vc-git-working-revision
281 4% - vc-git--rev-parse
281 4% - vc-git--out-ok
281 4% - apply
281 4% - vc-git--call
281 4% - apply
281 4% - process-file
281 4% apply
56 0% - vc-git--symbolic-ref
55 0% - vc-git--run-command-string
55 0% - apply
55 0% - vc-git--out-ok
55 0% - apply
55 0% - vc-git--call
55 0% - apply
55 0% - process-file
55 0% apply
283 4% - vc-call-backend
283 4% - apply
283 4% - vc-git-find-file-hook
283 4% - vc-state
283 4% - vc-state-refresh
283 4% - vc-call-backend
283 4% - apply
283 4% - vc-git-state
281 4% - apply
280 4% - vc-git--run-command-string
178 2% - apply
177 2% - vc-git--out-ok
177 2% - apply
177 2% - vc-git--call
177 2% - apply
173 2% - process-file
172 2% apply
102 1% file-relative-name
1 0% - vc-git--program-version
1 0% - vc-git--run-command-string
1 0% - apply
1 0% - vc-git--out-ok
1 0% - apply
1 0% - vc-git--call
1 0% - apply
1 0% - process-file
1 0% apply
1 0% version<=
56 0% - normal-mode
52 0% - set-auto-mode
52 0% - set-auto-mode--apply-alist
25 0% - set-auto-mode-0
25 0% - emacs-lisp-mode
16 0% - run-mode-hooks
13 0% - hack-local-variables
9 0% - hack-local-variables-prop-line
6 0% - set-auto-mode-1
5 0% inhibit-local-variables-p
2 0% file-remote-p
3 0% - run-hooks
3 0% - global-font-lock-mode-enable-in-buffers
3 0% - turn-on-font-lock-if-desired
3 0% - turn-on-font-lock
3 0% - font-lock-mode
3 0% - font-lock-default-function
3 0% - font-lock-mode-internal
3 0% - font-lock-turn-on-thing-lock
3 0% - jit-lock-register
2 0% - jit-lock-mode
1 0% add-hook
7 0% - lisp-data-mode
4 0% - prog-mode
2 0% add-hook
1 0% kill-all-local-variables
2 0% lisp-mode-variables
1 0% add-hook
8 0% assoc-default
4 0% - font-lock-mode
4 0% - font-lock-default-function
3 0% - font-lock-mode-internal
1 0% - font-lock-turn-on-thing-lock
1 0% jit-lock-register
1 0% - add-hook
1 0% - sort
1 0% #<compiled -0x6178706b98d8672>
71 1% - file-truename
55 0% - file-truename
47 0% - file-truename
34 0% - file-truename
21 0% - file-truename
11 0% file-truename
10 0% - insert-file-contents
10 0% - set-auto-coding
10 0% - find-auto-coding
9 0% auto-coding-alist-lookup
1 0% sgml-html-meta-auto-coding-function
4 0% abbreviate-file-name
295 4% - find-buffer-visiting
25 0% - file-truename
16 0% - file-truename
9 0% - file-truename
5 0% - file-truename
1 0% - file-truename
1 0% file-truename
2 0% abbreviate-file-name
256 3% abbreviate-file-name
24 0% - file-truename
17 0% - file-truename
10 0% - file-truename
7 0% - file-truename
4 0% - file-truename
3 0% file-truename
1 0% - create-file-buffer
1 0% - apply
1 0% - uniquify--create-file-buffer-advice
1 0% uniquify-rationalize-file-buffer-names
1 0% - kill-buffer
1 0% process-kill-buffer-query-function
6 0% - message
6 0% - float-time
4 0% - time-since
3 0% - byte-code
1 0% require
3 0% - elisp--preceding-sexp
3 0% forward-sexp
12 0% - minibuffer-complete
12 0% - completion-in-region
12 0% - completion--in-region
12 0% - #<compiled -0x1b9ffa9f1839062>
12 0% - apply
12 0% - #<compiled 0xde9be983a24fd0>
12 0% - completion--in-region-1
12 0% - completion--do-completion
8 0% - minibuffer-completion-help
5 0% - temp-buffer-window-show
5 0% - display-buffer
5 0% - display-buffer-at-bottom
4 0% - window--display-buffer
3 0% - #<compiled -0x189b60680cedbb15>
2 0% - display-completion-list
2 0% - run-hooks
2 0% - completion-setup-function
1 0% substitute-command-keys
1 0% - read-extended-command--affixation
1 0% - mapcar
1 0% #<compiled 0x589b0a2756da0d7>
1 0% fit-window-to-buffer
1 0% - split-window-no-error
1 0% split-window
3 0% - completion-all-completions
3 0% - completion--nth-completion
3 0% - completion--some
3 0% - #<compiled 0x1e98a616a148b8c2>
3 0% - completion-basic-all-completions
3 0% - completion-pcm--all-completions
3 0% - all-completions
3 0% - #<compiled 0x52202314d904927>
3 0% complete-with-action
4 0% - completion-try-completion
4 0% - completion--nth-completion
4 0% - completion--some
4 0% - #<compiled 0x1e98a616b048b8c2>
4 0% - completion-basic-try-completion
4 0% - try-completion
4 0% - #<compiled 0x52202314d904927>
4 0% complete-with-action
8 0% - execute-extended-command
8 0% - command-execute
8 0% - call-interactively
8 0% - funcall-interactively
8 0% profiler-report
6 0% - previous-line
6 0% - line-move
5 0% line-move-visual
133 1% - byte-code
133 1% - read-extended-command
133 1% - completing-read
133 1% - completing-read-default
23 0% read-from-minibuffer
545 8% + ...
38 0% + timer-event-handler
5 0% + redisplay_internal (C function)
1 0% + jit-lock--antiblink-post-command
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 13:51 ` Alan Third
@ 2023-10-05 14:01 ` Gerd Möllmann
2023-10-05 14:09 ` Gerd Möllmann
1 sibling, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 14:01 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
Alan Third <alan@idiocy.org> writes:
>> That's okay. What I meant was setting the old locale at the end.
>
> I've managed to reproduce this, and the time difference on my machine
> is ridiculous. From 4 seconds without the setlocale calls to 24
> seconds with.
>
Holy cow! You mean you removed the setlocale at the end, or what did
you do?
> And that's with a legitimate, installed, locale ID in both cases.
>
> I wonder if this is why some people report Emacs 29 on macOS to be
> noticeably slower. They, of course, blame the graphics changes, but
> with that sort of variation in time...
>
>> > Out of interest, when is it slow? Is it when we have an invalid locale
>> > ID?
>>
>> That's an interesting question--whatever I do on master, it's almost
>> equally slow :-).
>>
>> It would be nice if I could get at least the right character encoding on
>> my system... On the plus side, I at least know now what's happening,
>> although I don't know what to do.
>
> Indeed. I'm tempted to say we should revert the change since I now
> suspect I misunderstood how setlocale works when I wrote this and I'm
> not sure it's actually improving anything.
>
> OTOH, it would be good if we could get this to actually work and
> generate correct locale ID's for the system... But then, I don't know
> what *is* a correct locale ID for a system like yours...
Yeah :-(. AS I wrote in a different mail, even Terminal doesn't do it
"right". And I can't even find anywhere what would be Apple's preferred
way of doing this.
>> Aprt from that, I'm currently trying to get profiling working on my old
>> Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which
>> show the difference. That could maybe answer your question.
>>
>> Buhut... I can't currently get Instruments to work, which might be
>> related to the fact that I've updated my unsupported by Apple Macbook to
>> Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for
>> my display arrives soon, so that I can use my Mac mini again. A lot of
>> construction sites ahead :-).
>
> I couldn't even get the old commit to build, I had to use the current
> master and just revert to see the difference. So best of luck! :)
Thanks :-).
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 13:51 ` Alan Third
2023-10-05 14:01 ` Gerd Möllmann
@ 2023-10-05 14:09 ` Gerd Möllmann
2023-10-05 14:58 ` Alan Third
1 sibling, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 14:09 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
Alan Third <alan@idiocy.org> writes:
> Indeed. I'm tempted to say we should revert the change since I now
> suspect I misunderstood how setlocale works when I wrote this and I'm
> not sure it's actually improving anything.
I hadn't checked this before, but with the patch I sent, the slowness is
indeed gone. What a bloody mess, this stuff :-).
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 14:09 ` Gerd Möllmann
@ 2023-10-05 14:58 ` Alan Third
2023-10-05 15:11 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Alan Third @ 2023-10-05 14:58 UTC (permalink / raw)
To: Gerd Möllmann
Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
On Thu, Oct 05, 2023 at 04:09:36PM +0200, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
>
> > Indeed. I'm tempted to say we should revert the change since I now
> > suspect I misunderstood how setlocale works when I wrote this and I'm
> > not sure it's actually improving anything.
>
> I hadn't checked this before, but with the patch I sent, the slowness is
> indeed gone. What a bloody mess, this stuff :-).
Yeah.
To answer your question in the other email, I saw the improvement only
by removing the setlocale in the "if" statement. Your code has
something similar, but it shows the speed improvement anyway, so I'm
not sure what's happening differently.
I've gone over the NSLocale documentation and it appears it explicitly
supports locales like en_DE, but the "UNIX" side of macOS doesn't. I
suppose it should be possible to generate your own en_DE locale, but
that's a bit much, really.
I also prodded at the fallback "system" locale, but it doesn't even
provide a locale ID, so it's useless.
There's a couple of typos in your commit message.
Handle LANG on macOS differntly (bug#bug#65908)
^e ^
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 14:58 ` Alan Third
@ 2023-10-05 15:11 ` Gerd Möllmann
2023-10-05 16:29 ` Eli Zaretskii
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 15:11 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
Alan Third <alan@idiocy.org> writes:
> On Thu, Oct 05, 2023 at 04:09:36PM +0200, Gerd Möllmann wrote:
>> Alan Third <alan@idiocy.org> writes:
>>
>> > Indeed. I'm tempted to say we should revert the change since I now
>> > suspect I misunderstood how setlocale works when I wrote this and I'm
>> > not sure it's actually improving anything.
>>
>> I hadn't checked this before, but with the patch I sent, the slowness is
>> indeed gone. What a bloody mess, this stuff :-).
>
> Yeah.
>
> To answer your question in the other email, I saw the improvement only
> by removing the setlocale in the "if" statement. Your code has
> something similar, but it shows the speed improvement anyway, so I'm
> not sure what's happening differently.
I'm actually no longer sure I want to know :-).
> I've gone over the NSLocale documentation and it appears it explicitly
> supports locales like en_DE, but the "UNIX" side of macOS doesn't. I
> suppose it should be possible to generate your own en_DE locale, but
> that's a bit much, really.
Agree. If someone wants to do this for some reason, more power to them.
They could then set LANG to it. I won't do it for my case because I
don't have TUI appls that require it, AFAIK.
> I also prodded at the fallback "system" locale, but it doesn't even
> provide a locale ID, so it's useless.
>
>
> There's a couple of typos in your commit message.
>
> Handle LANG on macOS differntly (bug#bug#65908)
> ^e ^
Oops, thanks for spotting this.
Remains the question if that should go into emacs-29? I'm for not
rocking the boat too much. Although...
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 13:18 ` Gerd Möllmann
@ 2023-10-05 16:11 ` Eli Zaretskii
2023-10-05 16:33 ` Alan Third
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 16:11 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 15:18:42 +0200
>
> I'd like to propose the attached patch for problem of invalid LANG
> setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
> or something valid can't be deduced from the locale.
Why is it reasonable to force the UTF-8 codeset as the fallback?
What about having a variable exposed to Lisp that allows the users to
control the fallback value of LANG?
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 13:56 ` Gerd Möllmann
@ 2023-10-05 16:19 ` Eli Zaretskii
2023-10-05 16:26 ` Alan Third
2023-10-05 16:36 ` Gerd Möllmann
0 siblings, 2 replies; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 16:19 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 15:56:11 +0200
>
> To the question of profiling. I've now used the built-in profiler on
> the two commits, but I must say that I don't see where the difference
> comes from. These are debug builds, 5 runs of the benchmark.
Are you sure you haven't profiled the same build? The profiles look
almost identical.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:19 ` Eli Zaretskii
@ 2023-10-05 16:26 ` Alan Third
2023-10-05 16:43 ` Gerd Möllmann
2023-10-05 16:36 ` Gerd Möllmann
1 sibling, 1 reply; 45+ messages in thread
From: Alan Third @ 2023-10-05 16:26 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Gerd Möllmann, gregory, 65908, stefankangas, ccsmile2008
On Thu, Oct 05, 2023 at 07:19:20PM +0300, Eli Zaretskii wrote:
> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> > Date: Thu, 05 Oct 2023 15:56:11 +0200
> >
> > To the question of profiling. I've now used the built-in profiler on
> > the two commits, but I must say that I don't see where the difference
> > comes from. These are debug builds, 5 runs of the benchmark.
>
> Are you sure you haven't profiled the same build? The profiles look
> almost identical.
I'm wondering if that indicates the problem is in an externally called
application, like git. I notice VC is being used, and if I copy the
lisp directory into a non-VC'd directory and run the test there it's
significantly faster.
For some reason I can no longer replicate the problem though, so I
can't check this idea myself.
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 15:11 ` Gerd Möllmann
@ 2023-10-05 16:29 ` Eli Zaretskii
2023-10-05 16:39 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 16:29 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 17:11:09 +0200
>
> Remains the question if that should go into emacs-29? I'm for not
> rocking the boat too much. Although...
Let's see the final patch, and decide then.
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:11 ` Eli Zaretskii
@ 2023-10-05 16:33 ` Alan Third
2023-10-05 16:38 ` Gerd Möllmann
2023-10-05 17:02 ` Eli Zaretskii
0 siblings, 2 replies; 45+ messages in thread
From: Alan Third @ 2023-10-05 16:33 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Gerd Möllmann, gregory, 65908, stefankangas, ccsmile2008
On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote:
> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> > Date: Thu, 05 Oct 2023 15:18:42 +0200
> >
> > I'd like to propose the attached patch for problem of invalid LANG
> > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
> > or something valid can't be deduced from the locale.
>
> Why is it reasonable to force the UTF-8 codeset as the fallback?
Both the macOS terminals I have access to use UTF-8 as their default,
and I'm not sure if they even let you change it. Therefore it seemed
reasonable to me that the default for Emacs should also be UTF-8.
> What about having a variable exposed to Lisp that allows the users to
> control the fallback value of LANG?
Is this not too early in startup for that? If not then couldn't the
user just use setenv and avoid this whole thing?
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:19 ` Eli Zaretskii
2023-10-05 16:26 ` Alan Third
@ 2023-10-05 16:36 ` Gerd Möllmann
2023-10-05 17:04 ` Eli Zaretskii
1 sibling, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 16:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
>> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
>> Date: Thu, 05 Oct 2023 15:56:11 +0200
>>
>> To the question of profiling. I've now used the built-in profiler on
>> the two commits, but I must say that I don't see where the difference
>> comes from. These are debug builds, 5 runs of the benchmark.
>
> Are you sure you haven't profiled the same build? The profiles look
> almost identical.
Yes, I'm sure.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:33 ` Alan Third
@ 2023-10-05 16:38 ` Gerd Möllmann
2023-10-05 17:02 ` Eli Zaretskii
1 sibling, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 16:38 UTC (permalink / raw)
To: Alan Third; +Cc: Eli Zaretskii, 65908, stefankangas, gregory, ccsmile2008
Alan Third <alan@idiocy.org> writes:
> On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote:
>> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
>> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
>> > Date: Thu, 05 Oct 2023 15:18:42 +0200
>> >
>> > I'd like to propose the attached patch for problem of invalid LANG
>> > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
>> > or something valid can't be deduced from the locale.
>>
>> Why is it reasonable to force the UTF-8 codeset as the fallback?
>
> Both the macOS terminals I have access to use UTF-8 as their default,
> and I'm not sure if they even let you change it. Therefore it seemed
> reasonable to me that the default for Emacs should also be UTF-8.
Agree.
>> What about having a variable exposed to Lisp that allows the users to
>> control the fallback value of LANG?
>
> Is this not too early in startup for that? If not then couldn't the
> user just use setenv and avoid this whole thing?
I wonder that, too.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:29 ` Eli Zaretskii
@ 2023-10-05 16:39 ` Gerd Möllmann
2023-10-05 17:06 ` Eli Zaretskii
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 16:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
>> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
>> Date: Thu, 05 Oct 2023 17:11:09 +0200
>>
>> Remains the question if that should go into emacs-29? I'm for not
>> rocking the boat too much. Although...
>
> Let's see the final patch, and decide then.
Please find attached. Not much gas changed, though.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: LANG patch --]
[-- Type: text/x-patch, Size: 2621 bytes --]
From f1ba5bbbd9526197052949525d2ac680337b6d6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Thu, 5 Oct 2023 17:29:17 +0200
Subject: [PATCH] Handle LANG on macOS differently (bug#65908)
* src/nsterm.m (ns_init_locale): If LANG is set, try to use that,
otherwise try to deduce what LANG should be. Check is the result is
valid, and use LANG="en_US.UTF-8" if not.
---
src/nsterm.m | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/src/nsterm.m b/src/nsterm.m
index 4e0dfa58c63..56865987b93 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -554,29 +554,32 @@ - (unsigned long)unsignedLong
/* macOS doesn't set any environment variables for the locale when run
from the GUI. Get the locale from the OS and set LANG. */
{
- NSLocale *locale = [NSLocale currentLocale];
-
NSTRACE ("ns_init_locale");
- /* If we were run from a terminal then assume an unset LANG variable
- is intentional and don't try to "fix" it. */
- if (!isatty (STDIN_FILENO))
+ /* Either use LANG, if set, or try to construct LANG from
+ NSLocale. */
+ const char *lang = getenv ("LANG");
+ if (lang == NULL)
{
- char *oldLocale = setlocale (LC_ALL, NULL);
- /* It seems macOS should probably use UTF-8 everywhere.
- 'localeIdentifier' does not specify the encoding, and I can't
- find any way to get the OS to tell us which encoding to use,
- so hard-code '.UTF-8'. */
- NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
- [locale localeIdentifier]];
-
- /* Check the locale ID is valid and if so set LANG, but not if
- it is already set. */
- if (setlocale (LC_ALL, [localeID UTF8String]))
- setenv("LANG", [localeID UTF8String], 0);
+ const NSLocale *locale = [NSLocale currentLocale];
+ const NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8",
+ [locale localeIdentifier]];
+ lang = [localeID UTF8String];
+ }
- setlocale (LC_ALL, oldLocale);
+ /* Check if LANG can be used for initializing the locale. If not,
+ use a default setting. Note that Emacs' main will undo the
+ setlocale below, initializing the locale from the
+ environment. */
+ if (setlocale (LC_ALL, lang) == NULL)
+ {
+ const char *const default_lang = "en_US.UTF-8";
+ fprintf (stderr, "LANG=%s cannot be used, using %s instead.\n",
+ lang, default_lang);
+ lang = default_lang;
}
+
+ setenv ("LANG", lang, 1);
}
--
2.39.3 (Apple Git-145)
^ permalink raw reply related [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:26 ` Alan Third
@ 2023-10-05 16:43 ` Gerd Möllmann
0 siblings, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 16:43 UTC (permalink / raw)
To: Alan Third; +Cc: Eli Zaretskii, 65908, stefankangas, gregory, ccsmile2008
Alan Third <alan@idiocy.org> writes:
> On Thu, Oct 05, 2023 at 07:19:20PM +0300, Eli Zaretskii wrote:
>> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
>> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
>> > Date: Thu, 05 Oct 2023 15:56:11 +0200
>> >
>> > To the question of profiling. I've now used the built-in profiler on
>> > the two commits, but I must say that I don't see where the difference
>> > comes from. These are debug builds, 5 runs of the benchmark.
>>
>> Are you sure you haven't profiled the same build? The profiles look
>> almost identical.
>
> I'm wondering if that indicates the problem is in an externally called
> application, like git. I notice VC is being used, and if I copy the
> lisp directory into a non-VC'd directory and run the test there it's
> significantly faster.
>
> For some reason I can no longer replicate the problem though, so I
> can't check this idea myself.
It's ca. 50% faster when I copy the files somewhere else.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:33 ` Alan Third
2023-10-05 16:38 ` Gerd Möllmann
@ 2023-10-05 17:02 ` Eli Zaretskii
2023-10-05 17:15 ` Alan Third
1 sibling, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 17:02 UTC (permalink / raw)
To: Alan Third; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008
> Date: Thu, 5 Oct 2023 17:33:56 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
> ccsmile2008@outlook.com, 65908@debbugs.gnu.org,
> gregory@heytings.org, stefankangas@gmail.com
>
> On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote:
> > > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> > > Date: Thu, 05 Oct 2023 15:18:42 +0200
> > >
> > > I'd like to propose the attached patch for problem of invalid LANG
> > > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
> > > or something valid can't be deduced from the locale.
> >
> > Why is it reasonable to force the UTF-8 codeset as the fallback?
>
> Both the macOS terminals I have access to use UTF-8 as their default,
> and I'm not sure if they even let you change it. Therefore it seemed
> reasonable to me that the default for Emacs should also be UTF-8.
Are you saying that macOS doesn't support non-UTF-8 encodings?
> > What about having a variable exposed to Lisp that allows the users to
> > control the fallback value of LANG?
>
> Is this not too early in startup for that? If not then couldn't the
> user just use setenv and avoid this whole thing?
Maybe that's fine, I just asked a question.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:36 ` Gerd Möllmann
@ 2023-10-05 17:04 ` Eli Zaretskii
2023-10-05 17:15 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 17:04 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org, gregory@heytings.org, 65908@debbugs.gnu.org,
> stefankangas@gmail.com, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 18:36:15 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> >> Date: Thu, 05 Oct 2023 15:56:11 +0200
> >>
> >> To the question of profiling. I've now used the built-in profiler on
> >> the two commits, but I must say that I don't see where the difference
> >> comes from. These are debug builds, 5 runs of the benchmark.
> >
> > Are you sure you haven't profiled the same build? The profiles look
> > almost identical.
>
> Yes, I'm sure.
Then I guess the problem is not with the Emacs Lisp code, but either
with the primitives implemented in C or some programs (Git?) invoked
by this recipe.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 16:39 ` Gerd Möllmann
@ 2023-10-05 17:06 ` Eli Zaretskii
2023-10-05 18:08 ` Stefan Kangas
0 siblings, 1 reply; 45+ messages in thread
From: Eli Zaretskii @ 2023-10-05 17:06 UTC (permalink / raw)
To: stefankangas, Gerd Möllmann; +Cc: alan, 65908, gregory, ccsmile2008
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org, gregory@heytings.org, 65908@debbugs.gnu.org,
> stefankangas@gmail.com, ccsmile2008@outlook.com
> Date: Thu, 05 Oct 2023 18:39:56 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> >> Date: Thu, 05 Oct 2023 17:11:09 +0200
> >>
> >> Remains the question if that should go into emacs-29? I'm for not
> >> rocking the boat too much. Although...
> >
> > Let's see the final patch, and decide then.
>
> Please find attached. Not much gas changed, though.
If you-two consider this safe for Emacs 29.2, I don't mind.
Stefan?
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 17:04 ` Eli Zaretskii
@ 2023-10-05 17:15 ` Gerd Möllmann
2023-10-05 18:25 ` Alan Third
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 17:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas
Eli Zaretskii <eliz@gnu.org> writes:
>> > Are you sure you haven't profiled the same build? The profiles look
>> > almost identical.
>>
>> Yes, I'm sure.
>
> Then I guess the problem is not with the Emacs Lisp code, but either
> with the primitives implemented in C or some programs (Git?) invoked
> by this recipe.
I find Alans's idea pretty compelling. Alas, I don't know enough about
git's internals to tell what it does when locales aren't set up
right. But it's very plausible, given the profiler output.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 17:02 ` Eli Zaretskii
@ 2023-10-05 17:15 ` Alan Third
0 siblings, 0 replies; 45+ messages in thread
From: Alan Third @ 2023-10-05 17:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008
On Thu, Oct 05, 2023 at 08:02:41PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 5 Oct 2023 17:33:56 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
> > ccsmile2008@outlook.com, 65908@debbugs.gnu.org,
> > gregory@heytings.org, stefankangas@gmail.com
> >
> > On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote:
> > > > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org,
> > > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com
> > > > Date: Thu, 05 Oct 2023 15:18:42 +0200
> > > >
> > > > I'd like to propose the attached patch for problem of invalid LANG
> > > > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid,
> > > > or something valid can't be deduced from the locale.
> > >
> > > Why is it reasonable to force the UTF-8 codeset as the fallback?
> >
> > Both the macOS terminals I have access to use UTF-8 as their default,
> > and I'm not sure if they even let you change it. Therefore it seemed
> > reasonable to me that the default for Emacs should also be UTF-8.
>
> Are you saying that macOS doesn't support non-UTF-8 encodings?
No, because of the slightly unusual way macOS works, where any
graphical application doesn't inherit much of an environment the
terminals have to set it up. I was just copying what the terminals do
by default. When I say I don't know if they let you change it, I mean
in their settings. You can change it in the shell and the locale
command here shows, for example:
# locale -a | grep en_GB
en_GB.ISO8859-1
en_GB.UTF-8
en_GB.US-ASCII
en_GB
en_GB.ISO8859-15
So we could skip the UTF-8 part if it's the wrong thing to do, but
since everything else in macOS is unicode aware, I suspect we should
keep it.
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 17:06 ` Eli Zaretskii
@ 2023-10-05 18:08 ` Stefan Kangas
0 siblings, 0 replies; 45+ messages in thread
From: Stefan Kangas @ 2023-10-05 18:08 UTC (permalink / raw)
To: Eli Zaretskii, Gerd Möllmann; +Cc: alan, 65908, gregory, ccsmile2008
Eli Zaretskii <eliz@gnu.org> writes:
> If you-two consider this safe for Emacs 29.2, I don't mind.
>
> Stefan?
No objections here, thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 17:15 ` Gerd Möllmann
@ 2023-10-05 18:25 ` Alan Third
2023-10-05 18:33 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Alan Third @ 2023-10-05 18:25 UTC (permalink / raw)
To: Gerd Möllmann
Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
On Thu, Oct 05, 2023 at 07:15:49PM +0200, Gerd Möllmann wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > Are you sure you haven't profiled the same build? The profiles look
> >> > almost identical.
> >>
> >> Yes, I'm sure.
> >
> > Then I guess the problem is not with the Emacs Lisp code, but either
> > with the primitives implemented in C or some programs (Git?) invoked
> > by this recipe.
>
> I find Alans's idea pretty compelling. Alas, I don't know enough about
> git's internals to tell what it does when locales aren't set up
> right. But it's very plausible, given the profiler output.
OK, with Gerd's latest patch installed, I set my shell thus:
export LANG="en_GB.UTF-8"
export LC_COLLATE=
export LC_CTYPE=
export LC_MESSAGES=
export LC_MONETARY=
export LC_NUMERIC=
export LC_TIME=
export LC_ALL=
and run:
LANG=en_DE.UTF-8 src/emacs -Q
which prints:
LANG=en_DE.UTF-8 cannot be used, using en_US.UTF-8 instead.
and sure enough "C-u M-! locale" gives:
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
I then run the test script against the lisp directory in the emacs git repo:
--- files: 61, delta: 4.428015
Elapsed time: 4.432377s (0.161921s in 13 GCs)
"--- files: 61, delta: 4.428015"
--- files: 61, delta: 4.416348
Elapsed time: 4.421116s (0.150580s in 12 GCs)
"--- files: 61, delta: 4.416348"
--- files: 61, delta: 4.391077
Elapsed time: 4.395202s (0.150900s in 12 GCs)
"--- files: 61, delta: 4.391077"
Then against the same directory copied elsewhere:
--- files: 61, delta: 0.882561
Elapsed time: 0.887944s (0.138922s in 11 GCs)
"--- files: 61, delta: 0.882561"
--- files: 61, delta: 0.882582
Elapsed time: 0.887593s (0.139193s in 11 GCs)
"--- files: 61, delta: 0.882582"
--- files: 61, delta: 0.866825
Elapsed time: 0.871124s (0.122224s in 10 GCs)
"--- files: 61, delta: 0.866825"
Then I run:
LANG= src/emacs -Q
and run the test against the lisp directory in the repo:
--- files: 61, delta: 5.87121
Elapsed time: 5.875535s (0.160997s in 13 GCs)
"--- files: 61, delta: 5.87121"
--- files: 61, delta: 5.867494
Elapsed time: 5.871656s (0.150614s in 12 GCs)
"--- files: 61, delta: 5.867494"
--- files: 61, delta: 5.83144
Elapsed time: 5.862261s (0.163723s in 13 GCs)
"--- files: 61, delta: 5.83144"
and the lisp directory not in the lisp repo:
--- files: 61, delta: 0.869081
Elapsed time: 0.873759s (0.134711s in 11 GCs)
"--- files: 61, delta: 0.869081"
--- files: 61, delta: 0.873445
Elapsed time: 0.878768s (0.133343s in 11 GCs)
"--- files: 61, delta: 0.873445"
--- files: 61, delta: 0.870359
Elapsed time: 0.875465s (0.132767s in 11 GCs)
"--- files: 61, delta: 0.870359"
So the time with no git repo are near identical, but the times with a
git repo vary by over a second.
When I do "LANG=" it's trying to set the local to the empty string
because we only check if LANG is null, which it's not, it's the empty
string (I think) and that's resulting in a locale like (C-u M-! locale):
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL="C"
I don't think this is conclusive proof, but I think that either git or
VC have a problem with a slightly broken locale. I'm not saying
there's a bug here, it could simply be that we call git many times and
it's having to work out the locale each time from the dodgy input I've
given it.
(I tried en_GB without the UTF-8 coding and the times were pretty much
identical to the en_US.UTF-8 times.)
--
Alan Third
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 18:25 ` Alan Third
@ 2023-10-05 18:33 ` Gerd Möllmann
2023-10-05 18:46 ` Gerd Möllmann
0 siblings, 1 reply; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 18:33 UTC (permalink / raw)
To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas
Alan Third <alan@idiocy.org> writes:
> When I do "LANG=" it's trying to set the local to the empty string
> because we only check if LANG is null, which it's not, it's the empty
> string (I think) and that's resulting in a locale like (C-u M-! locale):
>
> LANG=
> LC_COLLATE="C"
> LC_CTYPE="C"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL="C"
That's a good point. I should also check if LANG is set but empty,
because "" changes the meaning of setlocale. I'll commit that in a
second :-).
> I don't think this is conclusive proof, but I think that either git or
> VC have a problem with a slightly broken locale. I'm not saying
> there's a bug here, it could simply be that we call git many times and
> it's having to work out the locale each time from the dodgy input I've
> given it.
Yeah, to me that makes a lot of sense.
^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS
2023-10-05 18:33 ` Gerd Möllmann
@ 2023-10-05 18:46 ` Gerd Möllmann
0 siblings, 0 replies; 45+ messages in thread
From: Gerd Möllmann @ 2023-10-05 18:46 UTC (permalink / raw)
To: ccsmile2008; +Cc: Alan Third, 65908, Eli Zaretskii, gregory, stefankangas
Committed to emacs-29 as aad8b5d78f306ac9ca0c03734524c9f49585bee8.
I'll close this bug, please reopen if it's not fixed for you in 29.2.
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2023-10-05 18:46 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-13 6:47 bug#65908: 29.1.50; Emacs 29 regresses on macOS Zhang Haijun
2023-10-04 5:44 ` Gerd Möllmann
2023-10-04 7:38 ` Eli Zaretskii
2023-10-04 7:50 ` Gerd Möllmann
2023-10-04 8:29 ` Stefan Kangas
2023-10-04 8:32 ` Gerd Möllmann
2023-10-04 9:02 ` Gregory Heytings
2023-10-04 9:12 ` Gerd Möllmann
2023-10-04 9:12 ` Stefan Kangas
2023-10-04 10:55 ` Gerd Möllmann
2023-10-04 12:43 ` Gerd Möllmann
2023-10-04 21:16 ` Alan Third
2023-10-05 5:41 ` Eli Zaretskii
2023-10-05 5:55 ` Gerd Möllmann
2023-10-05 6:08 ` Eli Zaretskii
2023-10-05 8:52 ` Gerd Möllmann
2023-10-05 9:48 ` Alan Third
2023-10-05 11:12 ` Gerd Möllmann
2023-10-05 13:18 ` Gerd Möllmann
2023-10-05 16:11 ` Eli Zaretskii
2023-10-05 16:33 ` Alan Third
2023-10-05 16:38 ` Gerd Möllmann
2023-10-05 17:02 ` Eli Zaretskii
2023-10-05 17:15 ` Alan Third
2023-10-05 13:51 ` Alan Third
2023-10-05 14:01 ` Gerd Möllmann
2023-10-05 14:09 ` Gerd Möllmann
2023-10-05 14:58 ` Alan Third
2023-10-05 15:11 ` Gerd Möllmann
2023-10-05 16:29 ` Eli Zaretskii
2023-10-05 16:39 ` Gerd Möllmann
2023-10-05 17:06 ` Eli Zaretskii
2023-10-05 18:08 ` Stefan Kangas
2023-10-05 13:56 ` Gerd Möllmann
2023-10-05 16:19 ` Eli Zaretskii
2023-10-05 16:26 ` Alan Third
2023-10-05 16:43 ` Gerd Möllmann
2023-10-05 16:36 ` Gerd Möllmann
2023-10-05 17:04 ` Eli Zaretskii
2023-10-05 17:15 ` Gerd Möllmann
2023-10-05 18:25 ` Alan Third
2023-10-05 18:33 ` Gerd Möllmann
2023-10-05 18:46 ` Gerd Möllmann
2023-10-05 8:58 ` Gregory Heytings
2023-10-05 9:03 ` Gregory Heytings
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).