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.
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
> 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.
> 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
> #ifdef USE_LOCALE
> /* locale-aware code */
> /* non-locale code */
> if (locale_is_not_C)
> /* locale-ware code */
> /* non-locale code */
> This practice should have minuscule impact, and it's probably the plan for
> the multibyte side of things as well.
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-11-26 20:04:12|
|Subject: Re: grant/revoke bug with delete/update|
|Previous:||From: Bruce Momjian||Date: 2001-11-26 19:41:23|
|Subject: Re: Call for objections: deprecate postmaster -o switch?|