| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:22:38 |
| Message-ID: | 20240409232238.gatarspyhuyhwng7@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2024-04-09 19:00:41 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I think we need to do something about the compile time of this file, even with
> > gcc. Our main grammar already is an issue and stacking all the ecpg stuff on
> > top makes it considerably worse.
>
> Seems reasonable, if we can.
>
> > 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.
> So that ought to dump core if you don't make all the productions
> return malloc'd strings. How did you work around that?
I just tried to get to the point of understanding the reasons for slow
compilation, not to actually keep it working :). I.e. I didn't.
> (Maybe it'd be okay to just leak all the strings?)
Hm. The input to ecpg can be fairly large, I guess. And we have fun code like
cat_str(), which afaict is O(arguments^2) in its memory usage if we wouldn't
free?
Not immediately sure what the right path is.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2024-04-09 23:29:38 | Re: post-freeze damage control |
| Previous Message | Andres Freund | 2024-04-09 23:11:37 | Re: Speed up clean meson builds by ~25% |