[Python-Dev] int(string)

[Adam Olsen]

On 10/22/05, Tim Peters <tim.peters at gmail.com> wrote:
> [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.

AMD Athlon 2500+, Linux 2.6.13, GCC 4.0.2

rhamph at factor:~/src/Python-2.4.1$ python2.4 -m timeit 'int("999999999")'
1000000 loops, best of 3: 0.834 usec per loop
rhamph at factor:~/src/Python-2.4.1$ ./python -m timeit 'int("999999999")'
1000000 loops, best of 3: 0.801 usec per loop
rhamph at factor:~/src/Python-2.4.1$ python2.4 -m timeit 'int("9")'
1000000 loops, best of 3: 0.709 usec per loop
rhamph at factor:~/src/Python-2.4.1$ ./python -m timeit 'int("9")'
1000000 loops, best of 3: 0.717 usec per loop

Originally I just tried the longer string so I hadn't noticed that the
smaller string was slightly slower.  Oh well, caveat emptor.

--
Adam Olsen, aka Rhamphoryncus