[Bug libc/18441] Performance regression due to strcoll_l changes

[daniel.lichtenberger at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18441

--- Comment #5 from Daniel Lichtenberger <daniel.lichtenberger at gmail dot com> ---
Created attachment 8347
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8347&action=edit
Small strcoll benchmark with thai strings

Attached a small benchmark that does the simplest collation test possible -
calling strcoll on two medium-sized TH (thai) strings in a loop. I hope the
upload doesn't mangle the UTF-8 encoding string literals.

On my desktop machine (a Core i5-3570K) and with glibc 2.19, 2000 calls
complete in 0.4s. With the current git master (commit
711f67a789ba3505ae7b071453763e06590aa245), this takes an astonishing 40 seconds
- or 20 ms per strcoll call.

I also used other (Western) strings for testing to make sure it wasn't my local
glibc build - they showed better performance in the current version, as
expected.

It's hard to follow the implementation in strcoll_l.c without a deeper
understanding of Unicode string collation rules - I don't know if the removal
of rule caching caused this issue, or a change in the locale tables that are
used in the algorithm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.