Re: B-Tree support function number 3 (strxfrm() optimization)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id 5415A843.3070602@vmware.com
обсуждение исходный текст
Ответ на Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Ответы 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>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Aussie timezone database changes incoming
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: alter user set local_preload_libraries.