Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows
Date
Msg-id 4bb62e36-2c8b-4edd-8f26-b5ad80ea6017@eisentraut.org
Whole thread Raw
In response to Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows
List pgsql-hackers
On 12.12.25 10:18, Nazir Bilal Yavuz wrote:
>>>> FWIW, Bilal and I had, IIRC, explicitly not enabled on windows CI because it
>>>> made the build process even slower. But perhaps we should re-measure the
>>>> difference and re-consider?
>>>>
>>>> Greetings,
>>>>
>>>> Andres Freund
>>> As long as you use Windows locale names once this patch is in place.
>>> Posix locale names will still incur the performance hit until the next
>>> gettext release. Once using the next gettext release there will not be a
>>> performance penalty for using an invalid locale on Windows.
>>
>> What I was referring to was that *building* with NLS support is slower than
>> building without, which is the reason why CI currently isn't testing NLS in
>> the "Windows - Server 2022, MinGW64 - Meson" task. Even with ccache, the CI
>> builds with mingw are pretty darn slow, adding the overhead of creating a good
>> number of additional files is (or was, haven't retested this recently) making
>> it even slower.
> 
> I tested this and the timings (minute:seconds) of running tests:
> 
> MinGW + NLS [1]: 16:01
> MinGW + Patch + NLS [2]: 13:57
> 
> I ran the CI again to make sure and the speed up was similar.

Andres was asking about the build time with and without NLS.

There is a note in .cirrus.tasks.yml:

     # Keep -Dnls explicitly disabled, as the number of files it creates 
causes a
     # noticeable slowdown.


I have been testing this a bit.  Locally, using MinGW, I was not able to 
detect any significant difference.  On CI runs, the numbers were to 
erratic to get any consistent sense.  The CI image for Visual Studio 
does not appear to have gettext tools installed, so I couldn't activate 
it there, and I don't have Visual Studio set up locally, so I haven't 
been able to test that.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PRI?64 vs Visual Studio (2022)
Next
From: Peter Eisentraut
Date:
Subject: Re: PRI?64 vs Visual Studio (2022)