Re: [HACKERS] palloc() vs static define?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] palloc() vs static define?
Дата
Msg-id 11333.913651233@sss.pgh.pa.us
обсуждение исходный текст
Ответ на palloc() vs static define?  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
> in commands/cluster.c, in function cluster, we define NewIndexName as:
> char    NewIndexName[NAMEDATALEN]; /* line 93 */
> in function copy_index, we define it as:
> char          *NewIndexName; /* line 246 */
> And then palloc(NAMEDATALEN) before it gets used...

> Now, which we use doesn't much matter to me, but I would think some sort
> of consistency would be in order...or am I missing something as far as
> each are concerned?  Is one method inheriently faster then another, or do
> they have about the same performance characteristics?

The first method (char name[SIZE]) is certainly far faster, since it is
just allocating local variable space during function entry.  In fact,
it's probably effectively *free*, zero cycles.  If you allocate any
local variable space in a function, then allocating more just means
subtracting a larger constant from the stack pointer.  palloc() is going
to go through the memory management code which is certainly not cheap
by comparison.

On the other hand, palloc easily supports asking for a variable amount
of space, whereas local array variables have to have a compile-time-
constant size.  (We ignore GNU-only language extensions here ;-).)
For this particular situation that's not a concern, but other places
you might have to use palloc.

The really critical issue is what lifetime the allocated space needs
to have.  A local array var will go away automatically at function
exit; palloc'd space lives until you pfree it or it gets cleaned up
during transaction exit.

In this particular situation, the local array var approach looks better
to me, but I wonder whether index_create is expecting to be handed a
pointer to persistent storage...
        regards, tom lane


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

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: [HACKERS] ecpg man page
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Does this make sense: