bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65908: 29.1.50; Emacs 29 regresses on macOS


From: Alan Third
Subject: bug#65908: 29.1.50; Emacs 29 regresses on macOS
Date: Thu, 5 Oct 2023 19:25:31 +0100

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]