Re: Mingw task for Cirrus CI - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Mingw task for Cirrus CI
Date
Msg-id 20220408220557.r3rw3ngi63mq36kv@alap3.anarazel.de
Whole thread Raw
In response to Re: Mingw task for Cirrus CI  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Mingw task for Cirrus CI  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

On 2022-04-08 17:04:34 +0200, Alvaro Herrera wrote:
> > Since dash won't help us to get the build time down sufficiently, and the
> > tests don't pass without a separate build tree, I looked at what makes
> > config/prep_buildtree so slow.
>
> Maybe we can replace prep_buildtree with a Perl script.  Surely that
> should be faster.

Currently building doesn't depend on perl :(

I think the improvements that I suggested are big enough that they're worth
doing on their own, particularly for windows, but also other OSs.


I just realized that the second find is pretty expensive compared to the
first.

time find "$sourcetree" -type d \( \( -name CVS -prune \) -o \( -name .git -prune \) -o -print \) | grep -v
"$sourcetree/doc/src/sgml/\+"> /dev/null
 
real    0m0.019s
user    0m0.008s
sys    0m0.017s

second:
time find "$sourcetree" -name Makefile -print -o -name GNUmakefile -print | grep -v "$sourcetree/doc/src/sgml/images/"
>/dev/null
 

real    0m0.118s
user    0m0.071s
sys    0m0.053s

It think we could just obsolete the second find, by checking for the existence
of Makefile / GNUmakefile in the first loop...


The invocation of ln -s is quite measurable - looks like it's mostly the
process startup overhead (on linux, at least). Doing a ln --version > /dev/null
each iteration takes about the same time as actually creating the symlinks.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Lowering the ever-growing heap->pd_lower
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman