Re: Make(1) patch

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

On Mon, Feb 09, 2009 at 10:02:27PM +0100, Reinoud Zandijk wrote:
> On Mon, Feb 09, 2009 at 09:56:23PM +0100, Martin Husemann wrote:
> > On Mon, Feb 09, 2009 at 09:47:20PM +0100, Reinoud Zandijk wrote:
> > > Any objections? Tested with pkgsrc, and it still works fine :)
> > 
> > What is the performance effect?
> 
> What i could measure from a simple Makefile (udfclient) it was clocked faster
> (not much though) after a few warm reruns compared to the stock -current one.
> It feels a bit faster though. A bigger performance test might be better, but i
> dont know how to reliably test it otherwise. With the huge amount of variables
> and other buf.c users in pkgsrc its performance might grow more.

You need to run some tests with much more complex makefiles.
Try nbmake in /lib/libc when there is nothing to compile,
or maybe 'nbmake obj' somewhere.

Also consider carefully the places where it actually might make a difference!
You are changing the behaviour when the initial buffer isn't large enough.
This is either a 256 byte buffer (the default) or a much smaller one (often
used for variable names).

If 256 bytes isn't enough, then it is extreme unlikely that 256+16 will
be any better!  And you really don't want to keep adding extra bits.

The other case is where we think we know the length, but keep on
having to extend - eg:

.for v in ${var_list}
vv += ${v}.foo
.endfor

again you don't want to keep adding little bits.
(perhaps the sizes should grow more rapidly! at least initially!)

        David

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