Re: [bug #35485] New $(.MFDIR) built-in variable

[Paul Smith]

On Sun, 2012-02-26 at 21:58 -0800, Howard Chu wrote:
> You've just described an O(n^2) behavior. This is definitely a drag;
> but it really depends on how heavily you make use of macros.

Well, in this case it depends on how heavily you make use of APPEND
operations on macros.  Is it worth adding a whole extra pointer
(possibly 8 bytes on a 64bit system) or even a length (4 bytes) to every
single macro in make, just so we can avoid a strlen() call when we want
to append to a macro (for example)?  Or doing some kind of powers of 2
buffer size thing to cut down on realloc() when most of the macros in
make are set to a static value and not changed?  How much memory are we
willing to waste on extra macro storage to make those relatively few
macros we DO expand more efficient?

> > The thing that DOES get noticeably more complex is manipulating the
> > variable as if it were a list, with functions like firstword, lastword,
> > etc. because those functions must first chop the string up into words,
> > then operate on those, and that happens every time the function is
> > invoked.
> 
> If that happens a lot, then you should simply construct the lists once
> and keep them...

In make everything is a time-space tradeoff.  If we know that the same
macro will be used constantly with functions that need to chop it into
words (and we know that we don't anticipate the value of the macro will
change much) then sure, it makes sense to keep around the "last" list:
we'll probably win by reusing it.  But if we don't ever need that list
of words again, or the value of the macro changes constantly (between
most uses of the "list" functions) then we're just wasting
memory--something make already uses quite a bit of for larger build
environments.

How can make know which macros it makes sense to treat specially and
which it doesn't?  You can invent all sorts of heuristics but I'm just
not convinced that it will help much on average, across all makefiles.
And I'm not convinced creating a lot of special handling for the very
few (builtin) macros we do know will likely benefit from that treatment
(like MAKEFILE_LIST) is worthwhile.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist