[Fredrik Lundh] > for the record, my little benchmark now runs about five > times faster than before -- which means that 16-bit find > is now ~30% faster than 8-bit find (barry? ;-) [Andrew M. Kuchling]/ > Speculation: the code in stringobject.c looks like this: > for (; i <= last; ++i) > if (s[i] == sub[0] && > (n == 1 || memcmp(&s[i+1], &sub[1], > n-1) == 0)) > return (long)i; > ... > the Unicode find is simpler, just doing the full memcmp. I wonder > if the extra n == 1 and i+1, n-1 arithmetic costs more than it > saves? So the intent of the code is to avoid the expense of calling memcmp if a full n-character memcmp can't possibly find equality at i (due to mismatch of first characters), and the assumption is that first characters mismatch frequently. Both seem like good calls to me! > This is probably delicately tied to the speed of your memcmp(). Also on whether your memcmp() is an actual external function or a full or partial inline expansion (e.g., the strcmp at KSR expanded into code much like the "by-hand" stuff above, skipping "the real" strcmp if the first characters weren't equal). > Anyone want to try the simpler version and report on whether > it makes a difference? No <wink>. But if someone does, a good compromise might be to split this into two loops, one for the n==1 case and another for n>1. The "+1/-1" are dubious in any case (i.e., "memcmp(s+i, sub, n) == 0" saves the fiddly arithmetic at the also-minor cost of making memcmp do one redundant character compare).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4