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] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |