From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speed up clean meson builds by ~25% |
Date: | 2024-04-09 23:44:03 |
Message-ID: | 3889130.1712706243@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> Why are strduping all of these?
>> IIRC, the issue is that the mechanism for concatenating the tokens
>> back together frees the input strings
> Ah, that explains it - but also seems somewhat unnecessary.
I experimented with replacing mm_strdup() with
#define mm_strdup(x) (x)
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.
As a comparison point, compiling gram.o on the same machine
takes 1.3sec. So I am seeing a problem here, sure enough,
although not as bad as it is in some other clang versions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-04-09 23:50:56 | Re: post-freeze damage control |
Previous Message | Peter Geoghegan | 2024-04-09 23:40:57 | Re: wal_consistemcy_checking clean on HEAD |