Tim Peters wrote: > I think that's unsustainable in this specific case: stringobject and > stropmodule contained several utility functions with the same names that > clearly started life as identical code. Over time they got out of synch, and > when they punched me in the face today, I had no idea which was "right" and > which "wrong". Turned out they both had the same bug, and the clearest way > to fix it in stringobject.c without leaving a more inconsistent x-module mess > was to bring the once-common utility routines back into synch. > > As /F said, though, the mymemreplace() approach is inefficient and "should > be" replaced wholesale. If that's done in stringobject.c alone, great, then > I won't care about the legacy routines in stropmodule.c either. as a footnote, SRE uses the same source code to generate both 8-bit and 16-bit versions of the match engine. I see no reason why we cannot do the same for the string operations (PyString, PyUnicode, and strop). if anyone wants me to look into this, just say "go ahead". > > no wonder u"".replace() is 30% faster than "".replace() ;-) > > For a given number of characters or bytes <wink>? characters. judging from the SRE benchmarks, modern platforms can process 16-bit characters as fast as they can process 8-bit characters. Cheers /F
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