Re: appendBinaryStringInfo stuff - Mailing list pgsql-hackers

From David Rowley
Subject Re: appendBinaryStringInfo stuff
Date
Msg-id CAApHDvo0Q9_6RdNxL_EgZhBAqEeTtLxd3m=G79movsNNNbByvA@mail.gmail.com
Whole thread Raw
In response to Re: appendBinaryStringInfo stuff  (Andres Freund <andres@anarazel.de>)
Responses Re: appendBinaryStringInfo stuff
Re: appendBinaryStringInfo stuff
List pgsql-hackers
On Mon, 19 Dec 2022 at 21:12, Andres Freund <andres@anarazel.de> wrote:
> Perhaps we should make appendStringInfoString() a static inline function
> - most compilers can compute strlen() of a constant string at compile
> time.

I had wondered about that, but last time I looked into it there was a
small increase in the size of the binary from doing it. Perhaps it
does not matter, but it's something to consider.

Re-thinking, I wonder if we could use the same macro trick used in
ereport_domain(). Something like:

#ifdef HAVE__BUILTIN_CONSTANT_P
#define appendStringInfoString(str, s) \
    __builtin_constant_p(s) ? \
        appendBinaryStringInfo(str, s, sizeof(s) - 1) : \
        appendStringInfoStringInternal(str, s)
#else
#define appendStringInfoString(str, s) \
    appendStringInfoStringInternal(str, s)
#endif

and rename the existing function to appendStringInfoStringInternal.

Because __builtin_constant_p is a known compile-time constant, it
should be folded to just call the corresponding function during
compilation.

Just looking at the binary sizes for postgres. I see:

unpatched = 9972128 bytes
inline function = 9990064 bytes
macro trick = 9984968 bytes

I'm currently not sure why the macro trick increases the binary at
all. I understand why the inline function does.

David



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Common function for percent placeholder replacement
Next
From: Mikhail Gribkov
Date:
Subject: Re: On login trigger: take three