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 <psm...@gnu.org> 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
