Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id 5415A843.3070602@vmware.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Re: B-Tree support function number 3 (strxfrm() optimization)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 09/13/2014 11:28 PM, Peter Geoghegan wrote:
> Anyway, attached rough test program implements what you outline. This
> is for 30,000 32 byte strings (where just the final two bytes differ).
> On my laptop, output looks like this (edited to only show median
> duration in each case):

Got to be careful to not let the compiler optimize away microbenchmarks
like this. At least with my version of gcc, the strcoll calls get
optimized away, as do the memcmp calls, if you don't use the result for
anything. Clang was even more aggressive; it ran both comparisons in 0.0
seconds. Apparently it optimizes away the loops altogether.

Also, there should be a setlocale(LC_ALL, "") call somewhere. Otherwise
it runs in C locale, and we don't use strcoll() at all for C locale.

After fixing those, it runs much slower, so I had to reduce the number
of strings. Here's a fixed program. I'm now getting numbers like this:

(baseline) duration of comparisons without useless memcmp()s: 6.007368
seconds

duration of comparisons with useless memcmp()s: 6.079826 seconds

Both values vary in range 5.9 - 6.1 s, so it's fair to say that the
useless memcmp() is free with these parameters.

Is this the worst case scenario?

- Heikki


Attachment

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Aussie timezone database changes incoming
Next
From: Peter Eisentraut
Date:
Subject: Re: alter user set local_preload_libraries.