Speed of str(positive_integer)..

[Tim Peters]

[Tony Meyer]
> ... 
> It does seem odd that "r,q = divmod(b,c)" is slower than "r = b//c;q =
> b-r*c" (or "r = b//c;q=b%c", which is better), but timeit shows that it is
> (with Python 2.3.4).  I suppose this is the penalty for the additional work
> that divmod does with checking signs and so on.

Integer // and integer % both work by invoking integer divmod
(i_divmod() in intobject.c) under the covers. // returns the first
result, and % returns the second.  So the faster ways actually compute
both the quotient and the remainder twice!

Looking up "divmod" is part of reason; that has to fail to find
"divmod" in the globals first, and then succeed finding "divmod" in
the builtins.

But that's not the bulk of the reason.  The primary reason calling
divmod is slower is the need to allocate and fill in divmod's 2-tuple
result.  For ints, that can be more expensive than the actual
arithmetic.

If you're using long ints instead, the time to lookup "divmod" and
build the tuple can be trivial compared to the time to do the actual
arithmetic, and then divmod is indeed twice as fast as doing it "the
fast" way <wink>; e.g.,

$ timeit.py -s a=10**300 -s b=2**100 divmod(a,b)
100000 loops, best of 3: 8.83 usec per loop

$ timeit.py -s a=10**300 -s b=2**100 a//b;a%b
100000 loops, best of 3: 17.1 usec per loop