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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Is it really such a good thing for newNode() to be a macro?
Дата
Msg-id 48B55BC6.7030704@enterprisedb.com
обсуждение исходный текст
Ответ на Is it really such a good thing for newNode() to be a macro?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Is it really such a good thing for newNode() to be a macro?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> I happened to be looking at nodes.h and started wondering just how
> sane this coding really is:
> 
> extern PGDLLIMPORT Node *newNodeMacroHolder;
> 
> #define newNode(size, tag) \
> ( \
>     AssertMacro((size) >= sizeof(Node)),        /* need the tag, at least */ \
>     newNodeMacroHolder = (Node *) palloc0fast(size), \
>     newNodeMacroHolder->type = (tag), \
>     newNodeMacroHolder \
> )
> 
> Given that we're calling palloc, it's not clear that saving one level of
> function call is really buying much; and what it's costing us is a store
> to a global variable that the compiler has no way to optimize away.
> On a lot of platforms, accessing global variables isn't especially
> cheap.  Also, considering that palloc0fast is a nontrivial macro, and
> that there are a LOT of uses of newNode(), we're paying rather a lot of
> code space for a pretty dubious savings.

Note that the MemSetLoop macro used in palloc0fast is supposed to be 
evaluated at compile time, so the code space taken by that macro isn't 
that big. Turning newNode into function would force it to be evaluated 
at run-time instead.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Another refactoring proposal: move stuff into nodes/nodeFuncs.[ch]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is it really such a good thing for newNode() to be a macro?