| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: Is it really such a good thing for newNode() to be a macro? |
| Date: | 2008-08-27 14:32:13 |
| Message-ID: | 48B5656D.6010909@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Note that the MemSetLoop macro used in palloc0fast is supposed to be
>> evaluated at compile time,
>
> Oooh, good point, I had forgotten about that little detail. Yeah,
> we'll lose that optimization if we move the code out-of-line.
Well, we could still have the MemSetTest outside the function, and
evaluated at compile-time, if we provided an aligned and unaligned
version of newNode:
#define newNode(size, tag) \
( \
AssertMacro((size) >= sizeof(Node)), /* need the tag, at least */ \
( MemSetTest(0, sz) ? \
newNodeAligned(CurrentMemoryContext, sz, tag) : \
newNodeNotAligned(CurrentMemoryContext, sz, tag))
And if you're worried about the function call overhead,
newNode(Not)Aligned could have the contents of MemoryContextAllocZero
inlined into it. Not sure how much optimization is worthwhile here..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-08-27 14:41:05 | Re: Is it really such a good thing for newNode() to be a macro? |
| Previous Message | Benedek László | 2008-08-27 14:17:43 | Re: pg_dump roles support |