Re: Mingw task for Cirrus CI

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Mingw task for Cirrus CI
Date: 2022-04-08 22:05:57
Message-ID: 20220408220557.r3rw3ngi63mq36kv@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-04-08 23:56:08 Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman
Previous Message Peter Geoghegan 2022-04-08 21:56:37 Re: Lowering the ever-growing heap->pd_lower