This is the mail archive of the glibc-bugs@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]

[Bug libc/15884] Big performance problem in strcoll


http://sourceware.org/bugzilla/show_bug.cgi?id=15884

--- Comment #5 from Ondrej Bilka <neleai at seznam dot cz> ---
On Sat, Aug 24, 2013 at 03:48:14AM +0000, siddhesh at redhat dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=15884
> 
> --- Comment #4 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
> Most of the time is spent in strlen:
> 
> samples  %        image name               symbol name
> 294712   97.3350  libc-2.15.so             __strlen_sse2
> 2650      0.8752  libc-2.15.so             strcoll_l
> 1646      0.5436  libc-2.15.so             _int_malloc
> 
> That is also unavoidable since the string length is necessary to allocate the
> index and rules cache.  Without the index and rules cache, real lookups that
> need more than a pass to run will be painfully slow as is evident in the
> fallback code I've written to avoid caching if there isn't enough memory.
> 
No, that is unavoidable for strings that need more than one pass ONLY.

Majority of calls end when first difference is found, no caching needed.

Also you do not need to know length for allocations. Use

newsize = size * 2;
newarray = realloc(array, size, newsize);

when you reach a boundary character.

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


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