Re: Make(1) patch

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Feb 09, 2009 at 09:47:20PM +0100, Reinoud Zandijk wrote:
> Hi folks,
> 
> looking at make(1)'s sources i came to the following patch; its not a big
> deal, but its exponentially allocating memory wich might not be wise for all
> architectures. It also doesn't try to allocate a power of two wich might
> otherwise be handy for pages.
...
> @@ -106,7 +102,7 @@ __RCSID("$NetBSD: buf.c,v 1.24 2009/01/1
>  void
>  Buf_Expand_1(Buffer *bp)
>  {
> -    bp->size += max(bp->size, 16);
> +    bp->size += 16;
>      bp->buffer = bmake_realloc(bp->buffer, bp->size);
>  }
>  
> @@ -130,7 +126,7 @@ Buf_AddBytes(Buffer *bp, int numBytes, c
>      Byte *ptr;
>  
>      if (__predict_false(count + numBytes >= bp->size)) {
> -     bp->size += max(bp->size, numBytes + 16);
> +     bp->size += (count + numBytes - bp->size) + 16;
>       bp->buffer = bmake_realloc(bp->buffer, bp->size);
>      }

You don't want to do it that way ...
I did an experiment once, and build.sh was slower.

The thing to remember is that some buffers get repeatedly extended.
So with your change they will get repeatedly reallocated.

The alternate thing is considering reducing the common default,
again enough buffers would get extended from 128 to 256 that
is also a loss.

I actually suspect that these malloc buffers are insignificant -
unless they have to be grown!

(Oh - the +16 were added recently because I couldn't guarantee
that the old size wasn't zero!)

There are much beter places to look for improving the performance of
make!

        David

-- 
David Laight: david%l8s.co.uk@localhost