[Bug libc/14613] New: missed optimization in strcspn

[eblake at redhat dot com]

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

             Bug #: 14613
           Summary: missed optimization in strcspn
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: eblake@redhat.com
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


I ran into an instance of someone using strcspn(var,"=") to find the offset of
a single rejection byte, and arguing that glibc should know better:
https://www.redhat.com/archives/libvir-list/2012-September/msg01630.html

The current glibc code is rather inefficient in this case; the naive C fallback
does a strchr(reject,s[i]) for each byte of s, and even the assembly versions
in the various .S files tend to start by computing a table of 256 bits (8
bytes) to learn which characters are in reject, before even starting to make a
pass through s.

But when the second argument of strcspn is exactly one byte long, it seems like
it should be much more efficient to do the equivalent of a single pass:
 strchrnul(s,*reject)-s
Since there is real code out there that uses strcspn() on single-byte
rejections in order to avoid a subtraction outside of the library code, it
seems like glibc should be catering to this optimization.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.