Hi,
On 2024-04-09 20:12:48 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > 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?
Tthere might be a quick-n-dirty way: We could make pgc.l return dynamically
allocated keywords.
Am I missing something, or is ecpg string handling almost comically
inefficient? Building up strings in tiny increments, which then get mashed
together to get slightly larger pieces, just to then be mashed together again?
It's like an intentional allocator stress test.
It's particularly absurd because in the end we just print those strings, after
carefully assembling them...
> 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.
I was wondering about something vaguely similar: Instead of concatenating
individual strings, append them to a stringinfo. The stringinfo can be reset
individually...
Greetings,
Andres Freund