Chris Down <[email protected]> writes: >> Interestingly I notice memmem() does _not_ have platform specific >>optimizations in glibc (apart from s390). It does use memchr() >>for len==1, but for len>=1 it's slower than say strstr() >>which does have x86 specific optimizations. >>So much so, I implemented memmem using strstr between (unlikely) NULs, >>and it was considerably faster. > > I didn't look at it for this case but I have noticed in the past the > places where glibc has arch specific optimisations and where it > doesn't can be rather surprising. For example I would have naively > thought memmem() with AVX2 should be derivable from the memchr() case.
The lack of optimized versions of memmem and strstr is not too surprising to me. Efficient (both time and space) string-searching algorithms are much more complex than the other string functions. Gnulib and glibc use the Two-Way algorithm [1]. The implementation doesn't look very fun to write in assembly [2], but that could be my lack of assembly talent speaking. :) > I'll take a look at that later this week and see whether things can be > improved there in glibc. Thanks for the pointer. That would be great. Thanks! Collin [1] https://en.wikipedia.org/wiki/String-searching_algorithm#Single-pattern_algorithms [2] https://github.com/coreutils/gnulib/blob/master/lib/str-two-way.h
