autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AS_VAR_APPEND


From: Eric Blake
Subject: Re: AS_VAR_APPEND
Date: Mon, 20 Oct 2008 15:16:50 -0700 (PDT)

Hi Ralf,

> Do you really want to replace all instances where variables are appended
> to?  Please note that it will likely slow down the code in most places.
> And since this is a pure speedup (as opposed to: correctness) issue, I'd
> not use it in places that only append a few times.
> The downside of this patch is that it reduces readability of configure a
> wee bit, and greppability (searching for 'var=' is quite helpful).

Valid points for limiting this to only the most-frequently appended
variables.  I'll respin the patch for review, trimming it to change only
the variables that are likely to be hit multiple times (for example, LIBS,
ac_header_list, ac_func_list), while leaving the more trivial uses (CC,
ac_configure_args,...) alone.  I also noticed some potential quoting
errors in my translation, where:

foo=$foo$bar
as_func_append foo $bar

can behave differently if $bar contains anything in $IFS (the latter
needs to use "$bar" to behave like the former).

> And that it adds a subshell fork to each configure and config.status
> invocation (but of course we need to pay that if we use it but once).

One additional overall fork in order to reduce overall complexity in large
projects.  No worse than autotest's fork for at_func_arith (which
I'm hoping to move into m4sh namespace soon).

> FWIW, when testing this for libtool, I think += was beneficial only when
> hundreds of items were appended, viz. when the length of $var was in
> several KB at least.

True - the quadratic cost of repeated appends (due to the linear cost
of individual appends) is only evident when there are lots of repeated
appends.  But for some configure variables, this is certainly the case.

> > +Emit shell code to append the shell expansion of @var{text} to the end
> > +of the current contents of the polymorphic shell variable @var{var}.  A
> > +naive implementation of this action scales quadratically,
> 
> That is not true.
> 
>    var=$var$text
> 
> typically scales at most linearly in the size of $var$text; if not, you
> should really get a better shell quickly.  Only when used many times in
> a row, is there some nonlinear scaling.  What you mean is that appending
> should use time linear in the size of the appended text, and amortized
> constant wrt. the size of the current contents.

Good points.  In other words:

single use: var=$var$text is typically linear, while var+=$text can be
amortized constant.

O(n) repeated use: var=$var$text is typically quadratic, while var+=$text
can be amortized linear.  But unless n (and thus $var) is large, the
difference is in the noise.

I'll try to clean up the wording to emphasize this distinction better,
as well as adding a recommendation that AS_VAR_APPEND is only
needed when the end result could be an arbitrarily large variable.
I won't push this topic to savannah until after round 2 of reviews.

-- 
Eric Blake

-- 
View this message in context: 
http://www.nabble.com/AS_VAR_APPEND-tp20069718p20079919.html
Sent from the Gnu - Autoconf - Patches mailing list archive at Nabble.com.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]