[HACKERS] -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=pigeondt=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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DCLOBBER_CACHE_ALWAYS build takes far longer than before
On Sun, 20 Apr 2008, Guillaume Smet wrote: Date: Sun, 20 Apr 2008 16:23:47 +0200 From: Guillaume Smet [EMAIL PROTECTED] To: pgsql-hackers list pgsql-hackers@postgresql.org, [EMAIL PROTECTED] 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=pigeondt=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: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DCLOBBER_CACHE_ALWAYS build takes far longer than before
Guillaume Smet [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] -DCLOBBER_CACHE_ALWAYS build takes far longer than before
On Sun, Apr 20, 2008 at 6:02 PM, Tom Lane [EMAIL PROTECTED] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
