tim.peters at gmail.com
Sat Oct 22 19:38:11 CEST 2005
>> I assume it's the overflow-checking that's the major time sink,
> 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.
> 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