"M.-A. Lemburg" wrote: > > Bill Tutt wrote: > > > > ! if (c1 > (1<<11) * 26) > > ! c1 += utf16Fixup[c1>>11]; > > ! if (c2 > (1<<11) * 26) > > ! c2 += utf16Fixup[c2>>11]; > > ! > > > > > > > > This change from the patch is kind of silly. You've made the code flow more > > complicated for no particularly good reason, > > The reason was that it avoids the fixup lookup for all non-surrogate > characters -- the vast majority of all chars processed. > > > esp. considering the size of > > utf16Fixup[]. That is, the cost in the CPU of handling the branch prediction > > is likely to be much higher than the array lookup for every character. > > Note that the lookup also involves a shift operation for every > character. > > But if you insist, I'll do some benchmarking and check which > version is faster. Your version: 0.98 sec. Fixed version: 0.96 sec. I don't think it's worth discussing this ;-) What's more interesting is that string compares are twice as fast: Same test: 0.46 sec. This is probably due to the compiler optimizing the memcmp() call which is used in string compares. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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