Optimizing of explicit temporary storage

[Nick Ing-Simmons]

Giovanni Bajo <giovannibajo@libero.it> writes:
>Nick Ing-Simmons wrote:
>
>>> it would be surprising to most programmers to optimize away the call
>>> because malloc *does* have side-effects on real systems.  For
>>> example, on UNIX, it is likely to call sbrk, which result in
>>> observable changes in the process state.
>> 
>> Indeed! - I have actually written
>> 
>> free(malloc(estimated_total_need));
>> 
>> To get expensive sbrk() call out of the way with one big one
>> rather than many smaller ones.
>
>So why not calling sbrk() directly?

Getting off-topic but:

Because calling sbrk() gives me once one big chunk of memory
not lots of little ones. So I would still have to "chip off" bits 
for each "object". 

In my case the malloc()s were in a library which was not to be 
re-coded, and were intermixed with free()s so simplistic slab 
allocator replacement didn't work well.

Emprically (on the Solaris 2.6 machine I was using at the time)
adding this:

  free(malloc(100000*sizeof(Foo));

Before code that had similar effect to:

  for (i=0; i < 100000; i++)
   {
    p = (Foo *) malloc(sizeof(Foo));  // really a library call as result of parse
   }

made it faster. Without the free(malloc()) it made a syscall 
to do the sbrk() for every "page or so" worth of heap it wanted.