Re: Speed up clean meson builds by ~25%

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Speed up clean meson builds by ~25%
Дата
Msg-id CA+TgmoZwg7O0AwYEx74_OTQdMYB3P-A02CBvtgR9QuboZpP+Ew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Speed up clean meson builds by ~25%  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Speed up clean meson builds by ~25%  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Apr 17, 2024 at 11:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think we should hold off on this.  I found a simpler way to address
> ecpg's problem than what I sketched upthread.  I have a not-ready-to-
> show-yet patch that allows the vast majority of ecpg's grammar
> productions to use the default semantic action.  Testing on my M1
> Macbook with clang 16.0.6 from MacPorts, I see the compile time for
> preproc.o in HEAD as about 1m44 sec; but with this patch, 0.6 sec.

If this is the consensus opinion, then
https://commitfest.postgresql.org/48/4914/ should be marked Rejected.
However, while I think the improvements that Tom was able to make here
sound fantastic, I don't understand why that's an argument against
Jelte's patches. After all, Tom's work will only go into v18, but this
patch could be adopted in v17 and back-patched to all releases that
support meson builds, saving oodles of compile time for as long as
those releases are supported. The most obvious beneficiary of that
course of action would seem to be Tom himself, since he back-patches
more fixes than anybody, last I checked, but it'd be also be useful to
get slightly quicker results from the buildfarm and slightly quicker
results for anyone using CI on back-branches and for other hackers who
are looking to back-patch bug fixes. I don't quite understand why we
want to throw those potential benefits out the window just because we
have a better fix for the future.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Comments on Custom RMGRs