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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] palloc() vs static define?
Date: 1998-12-14 16:00:33
Message-ID: 11333.913651233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The Hermit Hacker <scrappy(at)hub(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-12-14 16:20:50 Re: [HACKERS] Does this make sense:
Previous Message geek+ 1998-12-14 15:21:12 Re: [HACKERS] Does this make sense: