Re: Automatic PG_PRINTF_ATTRIBUTE
От | Noah Misch |
---|---|
Тема | Re: Automatic PG_PRINTF_ATTRIBUTE |
Дата | |
Msg-id | 20141122013025.GB1021580@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Automatic PG_PRINTF_ATTRIBUTE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: