RE: Patch: FYI: natFile -vs- stack

["Boehm, Hans" <hans_boehm at hp dot com>]

I agree with Bryce that __builtin_alloca should be significantly faster.  If
I gave a different impression, that was a mistake.  To properly account for
a short-lived heap allocation, you would also need to add in the appropriate
fraction of the GC cost, which is probably a bit more than the allocation
cost itself.

The other large advantage of stack allocation is that you tend to keep
reusing the same cache lines, where heap allocation tends to require a cache
miss (usually all the way to main memory) whenever you first access the new
object.

Hans

-----Original Message-----
From: Bryce McKinlay

Tom Tromey wrote:

>Bryce> I think its very unfortunate (for performance) to be allocating
>Bryce> on every stat() call etc. Is there no other way to fix this?
>Bryce> How about __builtin_alloca() ?
>
>I was reluctant to do that given that we don't have stack overflow
>checking.  Also in the past Hans has implied that heap allocating
>isn't necessarily much more expensive than stack allocating (or I've
>severely misread his comments, apologies for misrepresentations, etc).
>

I'd say that __builtin_alloca is always going to be faster simply 
because it avoids a function call. With thread local allocation, I guess

the _Jv_AllocBytes isn't going to be too bad, but without it heap 
allocation is certainly slower because syncronization is very very slow.