| From: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Bryan Green <dbryan(dot)green(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix severe performance regression with gettext 0.20+ on Windows |
| Date: | 2025-12-12 09:18:09 |
| Message-ID: | CAN55FZ1YXW77egh+33Ky7jME0sBYm3Bbojnk59R95HKA0ivciw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, 11 Dec 2025 at 20:49, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> 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.
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.
[1] https://cirrus-ci.com/task/5944143274311680
[2] https://cirrus-ci.com/task/5477244862201856
--
Regards,
Nazir Bilal Yavuz
Microsoft
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-12-12 09:33:47 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Bertrand Drouvot | 2025-12-12 09:00:08 | Re: Fix memory leak in gist_page_items() of pageinspect |