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/2005-October/057522.html below:

[Python-Dev] int(string)

[Python-Dev] int(string)Tim Peters tim.peters at gmail.com
Sat Oct 22 19:38:11 CEST 2005
[Tim]
>> I assume it's the overflow-checking that's the major time sink,

[Adam Olsen]
> Are you sure?

No -- that's what "assume" means <0.7 wink>.  For example, there's a
long chain of function calls involved in int(string) too.

> <https://sourceforge.net/tracker/index.php?func=detail&aid=1334979&group_id=5470&atid=305470>
>
> That patch removes the division from the loop (and fixes the bugs),
> but gives only a small increase in speed.

As measured how?  Platform, compiler, input, etc?  Is the "ULONG_MAX /
base" part compiled to inline code or to a call to a library routine
(e.g., if the latter, it could be that a dividend with "the sign bit
set" is extraordinarily expensive for unsigned division -- depends on
the <compiler, HW> pair in use)?  If so, a small static table could
avoid all runtime division.  If not, note that the number of divisions
hasn't actually changed for 1-character input.  Etc.

In any case, I agree it _should_ fix the bugs (although it also needs
new tests to verify that).
More information about the Python-Dev mailing list

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