This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15884] Big performance problem in strcoll
- From: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 24 Aug 2013 05:33:48 +0000
- Subject: [Bug libc/15884] Big performance problem in strcoll
- Auto-submitted: auto-generated
- References: <bug-15884-131 at http dot sourceware dot org/bugzilla/>
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.