Re: Locale timings

This is a common way of doing things inside glibc, and the happy result is that
if you really want to build a non-locale-aware system, you can use a
compile-time option that replaces the "locale_is_not_C" test with a constant.
It makes for more maintainable code because there's less chance for bitrot in
the usual case.

M

Peter Eisentraut wrote:

> I did some "benchmarks" to check whether --enable-locale with LC_ALL=C is
> just as fast as --disable-locale, to possibly justify making locale
> support the default. This test only covers locale-aware comparisons,
> which seems to be the critical aspect for all intents and purposes.
>
> I loaded a table of a single text column with 454240 rows of English
> words. The table had a size of 21.5 MB. The values were explicitly
> de-sorted, but the order was the same across all test runs. Then I ran
> SELECT * FROM test ORDER BY 1; and timed the wall-clock response time a
> few times. All configuration parameters were left at the default.
>
> The averaged results follow. Some logarithmic buffering cleverness
> appeared to surface, but the results are still distinct enough to be
> useful.
>
> no locale: 58s
> locale=C: 78s (ca. 33% slower)
> locale=en_US: 118s (ca. 100% slower)
>
> This confused me, because in my C library a strcoll() call with locale=C
> is handed to strcmp() quite directly. A look into varlena.c:varstr_cmp()
> shows that the locale-aware path does some extra copying because there is
> no strncoll() function we can use with non-terminated strings.
>
> For testing's sake I replaced the two palloc() calls in that function with
> alloca(), which is presumably the fastest possible memory allocator.
> Result:
>
> locale=C,alloca: 67s (ca. 15% slower)
>
> This shows that we're wasting quite a bit of time allocating memory --
> probably not only in this place. I'm pretty sure that the majority of the
> rest of the gap comes from the memcpy() operations. Not that there's a
> whole lot we can do about either of these things.
>
> However, I feel that we could reasonably cope with this situation by
> replacing
>
> #ifdef USE_LOCALE
> /* locale-aware code */
> #else
> /* non-locale code */
> #endif
>
> with
>
> if (locale_is_not_C)
> {
> /* locale-ware code */
> }
> else
> {
> /* non-locale code */
> }
>
> This practice should have minuscule impact, and it's probably the plan for
> the multibyte side of things as well.
>
>