Re: Speed up clean meson builds by ~25%
От | Andres Freund |
---|---|
Тема | Re: Speed up clean meson builds by ~25% |
Дата | |
Msg-id | 20240409232238.gatarspyhuyhwng7@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Speed up clean meson builds by ~25% (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Speed up clean meson builds by ~25%
|
Список | pgsql-hackers |
Hi, On 2024-04-09 19:00:41 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: