Re: Automatic PG_PRINTF_ATTRIBUTE - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Automatic PG_PRINTF_ATTRIBUTE
Date
Msg-id 20141122013025.GB1021580@tornado.leadboat.com
Whole thread Raw
In response to Re: Automatic PG_PRINTF_ATTRIBUTE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 21, 2014 at 08:13:17PM -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-11-21 03:12:14 -0500, Noah Misch wrote:
> >> ... I'm
> >> increasingly using an affected compiler, because it builds twice as quickly as
> >> today's gcc.
> 
> > No objections to the patch itself, but this seems like quite the odd
> > approach. Sure those old compilers might be a bit faster, but they also
> > report many fewer legitimate warnings and such.
> 
> > A full tree doesn't take that long? A full recompile sess than 40s here
> > and src/backend alone is much faster.

On my Windows development system, it improved a full build from 101s to 58s.
That felt substantial, but the risk around warnings is also substantial.  I
haven't bothered on non-Windows systems.  I suspect cross-compiling from
GNU/Linux would bring a greater speed improvement, but I have not tried.

> > ISTM that if it's currently too
> > slow, improving the concurrency of the build a bit more is a wiser
> > path...

True.  Moving from 8 cores to 32 cores gave a disappointing 29% improvement.
(You know build time is an obstacle when you start tracking these numbers.)

> As far as that goes, ccache is a miracle worker.  But I don't know
> how well it works on Windows :-(

Poorly, in my configuration, unless your cache hit rate is very high.  Adding
ccache increased the cold build time by 80%.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Automatic PG_PRINTF_ATTRIBUTE
Next
From: Alvaro Herrera
Date:
Subject: Re: How to use brin indexes?