Eric Bock <[EMAIL PROTECTED]> writes:
>> > 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!
>
> No; of course arbitrary limits are a horrible way to handle memory
> if it would be useful to have more memory later on.
Not in the least surprisingly, most interesting applications find it
"useful to have more memory later on". So this doesn't answer my
question: Is that a proposed alternative to malloc? If not, what is
the point of this?
>> > 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.
>
> Which is why I added 'sensibly' above :)
How does the 'sensibly' above relate to the heap getting fragmented
from using malloc?
>> > 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.
>
> My point is: unless there were thousands of memory allocations every
> second, the difference would be quickly lost in the network traffic.
This is not true, although it's easy to get into that mode of
thinking. I know because I used to share it. I'm not saying that I
became an Optimization Freak all of a sudden, just that profiling
showed that Wget's operation *as perceived by the user* can be
improved and that performance is not to be entirely disregarded on the
count of Wget being a "network utility".
>> I have gotten measurable and even visible improvements by profiling
>> parts of Wget.
>
> Certainly. Out of curiousity, what were they?
Are you asking for statistics or what changes I made?
>> > 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."
>
> Well, then, that's the fault of the programmer.
Whatever.
> It's clearly unsafe to use:
>
> char a[4000000000];
>
> isn't it?
It's clearly unsafe to beat your head with a huge stick while singing
the Marseillese. What's your point?
> If it can't allocate megabytes of memory, it's not interchangable
> with malloc,
Pbbt. I think I'm done with this silly discussion.
