Re: Improving prep_buildtree used in VPATH builds

On Fri, Nov 19, 2010 at 7:50 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Greg Smith's message of vie nov 19 01:52:34 -0300 2010:
>
>> I'd think that if configure takes
>> longer than it has to because the system is heavily loaded, the amount
>> compilation time is going to suffer from that would always dwarf this
>> component of total build time.  But if this was slow enough at some
>> point to motivate you to write a patch for it, maybe that assumption is
>> wrong.
>
> What if instead of -depth you do something like
> find the_args | sort -r
> ?  If you find a way to filter out the "parents" that you know have
> already been created, you could also cut down on the number of mkdir -p
> calls, which could result in a larger speedup.  And maybe we should
> remove the test -d.  Also, the `expr` call could be substituted by
> ${item##$sourcedir}, which is supposed to be a POSIX shell feature
> according to
> http://www.unix.org/whitepapers/shdiffs.html and
> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
>
> In short, there are plenty of optimization opportunities for this script
> without having to involve nonstandard constructs.

It seems that we have a general consensus that, aside from any
portability concerns (which so far seem to be mostly theoretical),
there's little to no evidence that it is a consistent win from a
performance standpoint. Alvaro wasn't able to demonstrate a win at
all, Tom theorized - albeit without evidence - that it might be a loss
under some circumstances, and Gurjeet (the OP) could only reproduce
about a ~4% speedup, amounting to 500 ms (although he did see an ~11%
speedup, amounting to 5 s, on one occasion). So I agree with Greg
Smith's comments a couple of days ago - it seems like this may not be
worth worrying about. I'm going to mark this Returned with Feedback
for now, though of course it can come back to life if more evidence
that this is the right thing to do comes to life.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company