Re: Is it really such a good thing for newNode() to be a macro?

I wrote:
> In theory the above implementation of newNode should be a clear win,
> so I'm thinking this result must be an artifact of some kind. I'm
> going to go try it on PPC and HPPA machines next; does anyone want to
> try it on something else?

Repeating the explain test on several machines, I get:

HPPA/HPUX: gcc-specific macro is about 1.5% faster than CVS HEAD
PPC/Darwin: gcc-specific macro is about 1% faster
x86/Darwin: seems to be a dead heat

So it seems that getting rid of the global doesn't really help on
current Intel hardware, but it does help on other architectures.
I'm pretty well convinced that the slowdown on my x86_64 machine is
an artifact that will disappear as soon as anybody changes the backend
code materially.

Accordingly, I'm going to go ahead with this:

#ifdef __GNUC__

/* With GCC, we can use a compound statement within an expression */
#define newNode(size, tag) \
({ Node *__result__; \
AssertMacro((size) >= sizeof(Node)); /* need the tag, at least */ \
__result__ = (Node *) palloc0fast(size); \
__result__->type = (tag); \
__result__; \
})

#else

old form of macro here

#endif /* __GNUC__ */

I'm not entirely sure whether ICC will take this, but the buildfarm
will tell us soon enough.

It's tempting to consider whether we should use this construct in place
of "static inline" functions elsewhere, such as list_length().

regards, tom lane