Patch: FYI: natFile -vs- stack

[Bryce McKinlay]

Tom Tromey wrote:

>>>This changes natFile.cc so that it doesn't stack allocate any
>>>buffers, and so that the buffers it allocates are the right size.
>>>
>
>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.

It isn't just a case of which is faster but also an issue of memory 
usage. Its easy to imagine the heap growing very quickly when someone 
gets a large directory of files and stats them all a few times. And this 
happens with nearly every query call in File!

Not having stack overflow checking is a separate issue. Allocating 
things on the stack doesn't make it any better or worse.

>We could cache the allocation.  This would make each File a bit
>larger.  This might make sense if we decide to use the locale's
>encoding for file names, since in that case converting from String to
>the char* array will be more expensive.
>

This would work too.

regards

Bryce.