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
