From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, samay sharma <smilingsamay(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Subject: | Re: [RFC] building postgres with meson - v12 |
Date: | 2022-09-04 06:12:52 |
Message-ID: | CAFBsxsGW=WRbnxXrc8UqqR479XuxtukSFWV-hnmtgsbuNAUO6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 2, 2022 at 11:35 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2022-09-02 14:17:26 +0700, John Naylor wrote:
> > On Thu, Sep 1, 2022 at 1:12 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > [v12]
> >
> > +# Build a small utility static lib for the parser. This makes it easier to not
> > +# depend on gram.h already having been generated for most of the other code
> > +# (which depends on generated headers having been generated). The generation
> > +# of the parser is slow...
> >
> > It's not obvious whether this is intended to be a Meson-only
> > optimization or a workaround for something awkward to specify.
>
> It is an optimization. The parser generation is by far the slowest part of a
> build. If other files can only be compiled once gram.h is generated, there's a
> long initial period where little can happen. So instead of having all .c files
> have a dependency on gram.h having been generated, the above makes only
> scan.c, gram.c compilation depend on gram.h. It only matters for the first
> compilation, because such dependencies are added as order-only dependencies,
> supplanted by more precise compiler generated dependencies after.
Okay, I think the comment could include some of this info for clarity.
> It's still pretty annoying that so much of the build is initially idle,
> waiting for genbki.pl to finish.
>
> Part of that is due to some ugly dependencies of src/common on backend headers
> that IMO probably shouldn't exist (e.g. src/common/relpath.c includes
> catalog/pg_tablespace_d.h).
Technically, *_d.h headers are not backend, that's why it's safe to
include them anywhere. relpath.c in its current form has to know the
tablespace OIDs, which I guess is what you think is ugly. (I agree
it's not great)
> Looks like it'd not be hard to get at least the
> _shlib version of src/common and libpq build without waiting for that. But for
> all the backend code I don't really see a way, so it'd be nice to make genbki
> faster at some point.
The attached gets me a ~15% reduction in clock time by having
Catalog.pm parse the .dat files in one sweep, when we don't care about
formatting, i.e. most of the time:
master:
User time (seconds): 0.48
Maximum resident set size (kbytes): 36112
patch:
User time (seconds): 0.41
Maximum resident set size (kbytes): 35808
That's pretty simple -- I think going beyond that would require some
perl profiling.
--
John Naylor
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
read-full-dat-file-at-once.patch | text/x-patch | 906 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-09-04 07:25:18 | Re: freeing LDAPMessage in CheckLDAPAuth |
Previous Message | Tom Lane | 2022-09-04 05:52:10 | Re: freeing LDAPMessage in CheckLDAPAuth |