Thread: -DCLOBBER_CACHE_ALWAYS build takes far longer than before

-DCLOBBER_CACHE_ALWAYS build takes far longer than before

From
"Guillaume Smet"
Date:
Hi all,

While working on our network problems to send the full build result to
the buildfarm server, I just saw that a full buildfarm run with
-DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
(from ~ 5h40 to 7h30).

This phenomenon has started with this run:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pigeon&dt=2008-04-12%2008:00:02

which has taken into account these commits:
pgsql/README 1.35
pgsql/contrib/ltree/ltree_io.c 1.15
pgsql/src/backend/parser/parse_type.c 1.95
pgsql/src/backend/utils/adt/tsquery.c 1.17
pgsql/src/backend/utils/adt/arrayfuncs.c 1.143
pgsql/src/backend/utils/adt/geo_ops.c 1.100
pgsql/src/backend/utils/mmgr/aset.c 1.77
pgsql/src/port/dirmod.c 1.53
pgsql/src/include/pg_config_manual.h 1.31
pgsql/src/include/port.h 1.120
pgsql/doc/TODO 1.2415
pgsql/doc/src/FAQ/TODO.html 1.921

The additional time is spread like this:
make check: 40 minutes
make installcheck: 34 minutes
make contrib installcheck: 10 minutes

I don't know if it's normal or not but I thought it's worth
mentioning. The standard build run on the same box isn't affected.

Olivier, do you have the same behaviour with jaguar?

-- 
Guillaume


Re: -DCLOBBER_CACHE_ALWAYS build takes far longer than before

From
ohp@pyrenet.fr
Date:
On Sun, 20 Apr 2008, Guillaume Smet wrote:

> Date: Sun, 20 Apr 2008 16:23:47 +0200
> From: Guillaume Smet <guillaume.smet@gmail.com>
> To: pgsql-hackers list <pgsql-hackers@postgresql.org>, ohp@pyrenet.fr
> Subject: -DCLOBBER_CACHE_ALWAYS build takes far longer than before
>
> Hi all,
>
> While working on our network problems to send the full build result to
> the buildfarm server, I just saw that a full buildfarm run with
> -DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
> (from ~ 5h40 to 7h30).
>
> This phenomenon has started with this run:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pigeon&dt=2008-04-12%2008:00:02
>
> which has taken into account these commits:
> pgsql/README 1.35
> pgsql/contrib/ltree/ltree_io.c 1.15
> pgsql/src/backend/parser/parse_type.c 1.95
> pgsql/src/backend/utils/adt/tsquery.c 1.17
> pgsql/src/backend/utils/adt/arrayfuncs.c 1.143
> pgsql/src/backend/utils/adt/geo_ops.c 1.100
> pgsql/src/backend/utils/mmgr/aset.c 1.77
> pgsql/src/port/dirmod.c 1.53
> pgsql/src/include/pg_config_manual.h 1.31
> pgsql/src/include/port.h 1.120
> pgsql/doc/TODO 1.2415
> pgsql/doc/src/FAQ/TODO.html 1.921
>
> The additional time is spread like this:
> make check: 40 minutes
> make installcheck: 34 minutes
> make contrib installcheck: 10 minutes
>
> I don't know if it's normal or not but I thought it's worth
> mentioning. The standard build run on the same box isn't affected.
>
> Olivier, do you have the same behaviour with jaguar?
>
>
Yes I do!
-- 
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges                +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


Re: -DCLOBBER_CACHE_ALWAYS build takes far longer than before

From
Tom Lane
Date:
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> While working on our network problems to send the full build result to
> the buildfarm server, I just saw that a full buildfarm run with
> -DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
> (from ~ 5h40 to 7h30).

It's probably due to the RANDOMIZE_ALLOCATED_MEMORY overhead added here:
> pgsql/src/backend/utils/mmgr/aset.c 1.77

Right now that's on by default in assert-enabled builds.  I'm not
sure if we want to leave it like that for long ...
        regards, tom lane


Re: -DCLOBBER_CACHE_ALWAYS build takes far longer than before

From
"Guillaume Smet"
Date:
On Sun, Apr 20, 2008 at 6:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  It's probably due to the RANDOMIZE_ALLOCATED_MEMORY overhead added here:
>
> > pgsql/src/backend/utils/mmgr/aset.c 1.77
>
>  Right now that's on by default in assert-enabled builds.  I'm not
>  sure if we want to leave it like that for long ...

OK. It's not a problem by itself. I just wanted to point it out.

Thanks.

-- 
Guillaume