A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-June/004757.html below:

[Python-Dev] talking about performance... [case closed]

[Python-Dev] talking about performance... [case closed]Andrew M. Kuchling akuchlin@mems-exchange.org
Tue, 20 Jun 2000 09:53:09 -0400
On Tue, Jun 20, 2000 at 12:15:01PM +0200, Fredrik Lundh wrote:
>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? ;-)

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;
 
It checks the first character, and then does the memcmp() skipping the
first character, or succeeds if the substring length is 1; 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?  This is
probably delicately tied to the speed of your memcmp().  Anyone want
to try the simpler version and report on whether it makes a difference?

--amk



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