This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
>>>>>
>>>>
>>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]