Skip site navigation (1) Skip section navigation (2)

Re: Inlining comparators as a performance optimisation

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inlining comparators as a performance optimisation
Date: 2011-12-05 13:23:45
Message-ID: 4EDCC5E1.4010204@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 05.12.2011 02:14, Peter Geoghegan wrote:
> On 4 December 2011 19:17, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>> I have not done any performance testing on this patch, but it might be
>> interesting to check it with the same test cases Peter's been using.
>
> I've attached a revision of exactly the same benchmark run to get the
> results in results_server.ods .
>
> You'll see very similar figures to results_server.ods for HEAD and for
> my patch, as you'd expect. I think the results speak for themselves. I
> maintain that we should use specialisations - that's where most of the
> benefit is to be found.

I'm still not convinced the big gain is in inlining the comparison 
functions. Your patch contains a few orthogonal tricks, too:

* A fastpath for the case of just one scankey. No reason we can't do 
that without inlining.

* inlining the swap-functions within qsort. Thaẗ́'s different from 
inlining the comparison functions, and could be done regardless of the 
data type. The qsort element size in tuplesort.c is always sizeof(SortTuple)

And there's some additional specializations we can do, not implemented 
in your patch, that don't depend on inlining the comparison functions:

* A fastpath for the case of no NULLs
* separate comparetup functions for ascending and descending sorts (this 
allows tail call elimination of the call to type-specific comparison 
function in the ascending version)
* call CHECK_FOR_INTERRUPTS() less frequently.

To see how much difference those things make, I hacked together the 
attached patch. I didn't base this on Robert's/Tom's patch, but instead 
just added a quick & dirty FunctionCallInvoke-overhead-skipping version 
of btint4cmp. I believe that aspect of this patch it's similar in 
performance characteristics, though.

In my quick tests, it gets quite close in performance to your inlining 
patch, when sorting int4s and the input contains no NULLs. But please 
give it a try in your test environment, to get numbers comparable with 
your other tests.

Perhaps you can get even more gain by adding the no-NULLs, and asc/desc 
special cases to your inlining patch, too, but let's squeeze all the fat 
out of the non-inlined version first. One nice aspect of many of these 
non-inlining optimizations is that they help with external sorts, too.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Attachment: misc-qsort-optimizations-1.patch
Description: text/x-diff (7.9 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Oleg BartunovDate: 2011-12-05 13:49:45
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
Previous:From: Yeb HavingaDate: 2011-12-05 10:06:47
Subject: Re: [REVIEW] Patch for cursor calling with named parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group