Hi, On 2025-12-11 11:45:01 -0600, Bryan Green wrote: > On 12/11/2025 10:05 AM, Andres Freund wrote: > > On 2025-12-11 15:43:36 +0100, Peter Eisentraut wrote: > >> On 10.12.25 01:45, Bryan Green wrote: > >>> The attached patch takes a pragmatic approach: for gettext 0.20.1+, we > >>> avoid triggering the bug by using Windows locale format instead of > >>> calling IsoLocaleName(). This works because gettext 0.20.1+ internally > >>> converts the Windows format back to POSIX for catalog lookups, whereas > >>> 0.19.8 and earlier need POSIX format directly. > >> > >> I can confirm that this patch fixes the performance deviation from > >> activating --enable-nls on Windows (tested with MSYS2/UCRT64). > > > > 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. Greetings, Andres Freund
