[Patch v2] [BZ 15884] strcoll: improve performance by removing the cache

[Stefan Liebler]

Hi Leonhard,

i filed a bug.
See: https://sourceware.org/bugzilla/show_bug.cgi?id=17506

Bye
Stefan

On 10/23/2014 02:27 PM, Leonhard Holz wrote:> Hi Stefan,
 >
 > looks like this has to be changed in test-skeleton.c. Can you file a bug
 > report for the problem?
 >
 > Best,
 > Leonhard
 >
 > Am 23.10.2014 12:18, schrieb Stefan Liebler:
 >> Hi Leonhard,
 >> the testcase timed out after 300s before the patch,
 >> which is interpreted as passing.
 >> Bye
 >>
 >> On 10/22/2014 10:39 PM, Leonhard Holz wrote:
 >>> Hi Stefan,
 >>>
 >>> is this a new problem or did it occure before the patch?
 >>>
 >>> Best,
 >>> Leonhard
 >>>
 >>> Am 22.10.2014 17:13, schrieb Stefan Liebler:
 >>>> Hi Leonhard,
 >>>>
 >>>> great job.
 >>>> If I run make xcheck on s390x, I get a failure in
 >>>> string/tst-strcoll-overflow testcase. See tst-strcoll-overflow.out:
 >>>> 0
 >>>> Expected signal 'Alarm clock' from child, got none
 >>>>
 >>>> I measured the execution time of this testcase between 35...60s
 >>>> which is smaller than the defined timeout of 300s.
 >>>> Can you change the behaviour of the testcase that it is passing
 >>>> if it was timed out or if it returns successfully without timeout.
 >>>>
 >>>> Bye
 >>>> Stefan
 >>>>
 >>>> On 10/14/2014 03:11 PM, Leonhard Holz wrote:
 >>>>> Hello everybody,
 >>>>>
 >>>>> this is a path that should solve bug 15884. It complains about the
 >>>>> performance of strcoll(). It was found out that the runtime of
 >>>>> strcoll()
 >>>>> is actually bound to strlen which is needed for calculating the
 >>>>> size of
 >>>>> a cache that was installed to improve the comparison performance.
 >>>>>
 >>>>> The idea for this patch was that the cache is only useful in rare
 >>>>> cases
 >>>>> (strings of same length and same first-level-chars) and that it
 >>>>> would be
 >>>>> better to avoid memory allocation at all. To prove this I wrote a
 >>>>> performance test bench-strcoll.c with test data in
 >>>>> benchtests-strcoll.tar.gz. Also modifications in benchtests/Makefile
 >>>>> and
 >>>>> localedata/Makefile are necessary to make it work.
 >>>>>
 >>>>> After removing the cache the strcoll method showed the predicted
 >>>>> behavior (getting slightly faster) in all but the test case for hindi
 >>>>> word sorting. This was due the hindi text having much more equal 
words
 >>>>> than the other ones. For equal strings the performance was worse 
since
 >>>>> all comparison levels were run through and from the second level on
 >>>>> the
 >>>>> cache improved the comparison performance of the original version.
 >>>>>
 >>>>> Therefore I added a bytewise test via strcmp iff the first level
 >>>>> comparison found that both strings did match because in this case
 >>>>> it is
 >>>>> very likely that equal strings are compared. This solved the problem
 >>>>> with the hindi test case and improved the performance of the others.
 >>>>>
 >>>>
 >>>
 >>
 >