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 3892940.1712707968@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speed up clean meson builds by ~25%  (Andres Freund <andres@anarazel.de>)
Responses Re: Speed up clean meson builds by ~25%
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2024-04-09 19:44:03 -0400, Tom Lane wrote:
>> As you did, I wasn't trying to get to a working result, so I didn't do
>> anything about removing all the free's or fixing the cast-away-const
>> warnings.  The result was disappointing though.  On my Mac laptop
>> (Apple clang version 15.0.0), the compile time for preproc.o went from
>> 6.7sec to 5.5sec.  Which is better, but not enough better to persuade
>> me to do all the janitorial work of restructuring ecpg's
>> string-slinging.  I think we haven't really identified the problem.

> With what level of optimization was that?  It kinda looks like their version
> might be from before the worst of the issue...

Just the autoconf-default -O2.

> FWIW, just redefining mm_strdup() that way doesn't help much here either,
> even with an affected compiler. The gain increases substantially after
> simplifying unreserved_keyword etc to just use the default action.

Hm.

In any case, this is all moot unless we can come to a new design for
how ecpg does its string-mashing.  Thoughts?

I thought for a bit about not allocating strings as such, but just
passing around pointers into the source text plus lengths, and
reassembling the string data only at the end when we need to output it.
Not sure how well that would work, but it could be a starting point.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Speed up clean meson builds by ~25%
Next
From: Andres Freund
Date:
Subject: Re: Speed up clean meson builds by ~25%