Re: strpbrk, strspn, and strcspn optimization suggestion

[Ulrich Drepper <drepper at redhat dot com>]

> Do you think this optimization is worth including in glibc?

The TLS data required is a killer.

Each of the functions would need 256 bytes for each thread (well, maybe
you can get by with one table per thread, but still).  That memory is
allocated for every thread, regardless of whether the functions are used
or not.  Data I collected (and posted here) showed that how very few
calls there are on a regular system which use these functions.  I don't
say that there are no programs which don't use them often.  But we are
talking here about the standard runtime shared by all programs and I
think the costs trump the benefits.  Just look at the additional memory
requirements for programs with hundreds or thousands of threads and
programs which need to start threads very often (the TLS memory must be
reinitialized each time a new thread is created).

I think this nifty implementation is better of as a separate piece of
code in which case you might even get by with a regular static array
instead of an array in TLS if the code is never used by more than one
thread at a time.

If you want, you can do some measurements.  Add a TLS array, measure
startup times, memory consumption, and the actual speed advantages you
get.  Also, there might be another possibility for optimization of said
functions: if the memory initialization dominates the cost (and 256
bytes are more than one cache line on most machines), represent each
character by a bit and use shift operations.  On modern machines this
might be faster but I never tried it.

-- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â

Attachment: signature.asc
Description: OpenPGP digital signature