On Mon, 18 Jun 2001, Hrvoje Niksic wrote:
> 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. But there are cases where a hard limit
would make more sense than a soft limit, and vice versa.
> > 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 :)
> > 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.
> I have gotten measurable and even visible improvements by profiling parts of Wget.
Certainly. Out of curiousity, what were they?
> > 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. It's still possible to notice
that malloc failed, and exit gracefully or whatever, instead of dumping core or
BSOD'ing the end user.
> > 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.
Well, most stacks are larger than 100 bytes :)
It's clearly unsafe to use:
char a[4000000000];
isn't it?
> 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.
If it can't allocate megabytes of memory, it's not interchangable with malloc,
and can only be relied upon in cases where very small amounts of memory are
involved. In those cases, it makes as much sense to say:
char buf[1024];
as it does to say:
char *buf = alloca(strlen(filename));
although the first is possibly clearer.
> >> 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?
Just that it's probably a bit of a headache that, at some point, a very
stealthy but occasionally fatal bug involving memory was introduced. And the
minor tangential argument about alloca on the mailing list probably is too :)
--
/* Eric */main(s,i,j,k,c){char*p=malloc(s=1),*a=p+(*p=i=j=k=0)/* Bock */
;while(~(*a=getchar())&&(++a-p<s||(a=(p=realloc(p,s+s))+s)&&(s+=s))||(*a
=0));for(a=malloc(s=1),*a=0;(c=p[i])&&(c=='+'&&++a[j]||c=='-'&&--a[j]||c
=='>'&&(++j<s||(a=realloc(a,s+s))&&memset(a+s,0,s)&&(s+=s))||c=='<'&&j--
||c=='.'&&~putchar(a[j])||c==','&&~(a[j]=getchar()))|!strchr("><.,",c);i
++)while((c=='['&&!a[j]||c==']'&&a[j])&&(k+=(p[i]=='[')-(p[i]==']'))&&p[
i+=c/* Brainf*** */=='[']&&(/* worse than */i-=c==']'/* this sig! */));}
