Re: Speed up clean meson builds by ~25% - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Speed up clean meson builds by ~25%
Date
Msg-id 1719013.1713409853@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speed up clean meson builds by ~25%  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: Speed up clean meson builds by ~25%
Re: Speed up clean meson builds by ~25%
List pgsql-hackers
Jelte Fennema-Nio <postgres@jeltef.nl> writes:
> As I expected this problem was indeed fairly easy to address by still
> building "backend/parser" before "interfaces". See attached patch.

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.

The core idea of the patch is to get rid of <str> results from
grammar nonterminals and instead pass the strings back as yylloc
results, which we can do by redefining YYLTYPE as "char *"; since
ecpg isn't using Bison's location logic for anything, this is free.
Then we can implement a one-size-fits-most token concatenation
rule in YYLLOC_DEFAULT, and only the various handmade rules that
don't want to just concatenate their inputs need to do something
different.

The patch presently passes regression tests, but its memory management
is shoddy as can be (basically "leak like there's no tomorrow"), and
I want to fix that before presenting it.  One could almost argue that
we don't care about memory consumption of the ecpg preprocessor;
but I think it's possible to do better.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Popcount optimization using AVX512
Next
From: Nathan Bossart
Date:
Subject: improve performance of pg_dump --binary-upgrade