Eric Bock <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2001, Hrvoje Niksic wrote:
>>
>> * Reduced memory fragmentation -- you don't need to worry about
>> thousands of small mallocs fragmenting your heap, alloca always
>> allocates and flawlessly frees stuff off the stack.
>
> This is why many people allocate all the memory they will need at
> the beginning, and either never allocate memory again, or reallocate
> it (sensibly) as needed.
Thanks, but no thanks. Such programs are frought with arbitrary
limits just so they can fit the convoluted memory management scheme
they deploy. Is *that* what you propose one should use instead of
malloc? I choose alloca any time!
>> * Faster resulting code -- alloca generates the code that simply moves
>> the stack pointer. malloc on the other hand is a genuine function
>> call which needs to search the heap for a "good match", resize the
>> heap if necessary, handle freeing, and be all around as fast as a
>> rabbit and as memory-efficient as the proverbial Scott with his
>> money, all at the same time. Obviously, one of these has to suffer.
>
> alloca is faster, but the difference is measured in microseconds.
Not once the heap gets fragmented. And it *will* get fragmented if
you are completely careless about allocating and deallocating small
chunks of memory.
> Considering that a single ping may be hundreds of milliseconds, this
> is trivial.
This is a non-sequitur. The fact that the network can be slow have
nothing to do with the speed of other operations Wget is doing. You
may find it hard to believe, but I have gotten measurable and even
visible improvements by profiling parts of Wget. This is especially
important when downloading from local networks. You may consider it
inconsequential, but people do care about this kind of stuff.
> Also malloc is guaranteed to return NULL if the memory isn't
> available, and can be recovered from that way...
"Recovered"? Don't make me laugh! Few programs do anything smarter
than bomb if malloc returns NULL, or perhaps "try again, then bomb."
Not to mention that malloc can fail just as miserably if your OS
overcommits by default.
> alloca is just as safe as declaring a fixed-size array larger than
> the stack size;
I just love this "argument". That's like saying that
char a[100]
is somehow "unsafe" because it won't "return NULL" if there is no room
on the stack.
Or why not claim that function calls should not be used because they
can randomly fail if there is no room on the stack. Or why we're at
it, let's make all the variables static. After all, those that don't
fit in registers have to be placed -- on the stack.
If there's no more place on the stack, you're done, and nothing can
save you. If the application misuses alloca to allocate megabytes of
memory, it's a poorly written application. I never claimed alloca
saved all the world's problems, but the "it doesn't return NULL"
argument is simply ridiculous.
>> So far, the amount of headache has been 0, whereas the benefits have
>> been significant.
>
> Until now, perhaps :)
Just what exactly are you trying to prove here? That I had or will
have huge problems with alloca? That I had no benefits? Please speak
for yourself and for your experiences with the programs you've
written.
