From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inlining comparators as a performance optimisation |
Date: | 2011-09-20 02:51:32 |
Message-ID: | 27619.1316487092@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> Once the cache has been warmed, explain analyze very consistently
> reports a runtime of 123ms for this query on master/HEAD, which varies
> +/- 1 ms, with a few outliers of maybe +/- 2ms. However, when I apply
> this patch, that goes down to 107ms +/- 1ms at -O0. I think that
> that's a pretty good start. Funnily enough, the difference/advantage
> vanishes at -O2 (I'm guessing that the higher optimisation level of
> GCC 4.5 hyper-corrects away the inlining, but I don't have time to
> check that right now).
Considering that -O2 is our standard optimization level, that
observation seems to translate to "this patch will be useless in
practice". I think you had better investigate that aspect in some
detail before spending more effort.
> This performance patch differs from most in that it's difficult in
> principle to imagine a performance regression occurring.
Really? N copies of the same code could lead to performance loss just
due to code bloat (ie, less of a query's inner loops fitting in CPU
cache). Not to mention the clear regression in maintainability. So
I'm disinclined to consider this sort of change without a significantly
bigger win than you're suggesting above (no, I don't even consider the
-O0 number attractive, let alone what you're finding at -O2).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Darren Duncan | 2011-09-20 03:20:39 | Re: Is there really no interest in SQL Standard? |
Previous Message | Tom Lane | 2011-09-20 02:04:25 | Re: File not found error on creating collation |