Speed of str(positive_integer)..

[alejandro david weil]

I asked myself how much slower would be an integer-positive number to
string convertion function against the default str().

And this function:

def myconv(number):
if number==0:
return '0'
s = ''
l = dig
while number > 0:
n = number//10
t = number-((n*10))
s = l[t]+s
number = n
return s

throw these results (using Psyco):

Testing 10000 times with numbers upto: 100
------------------------------------------
str(object) -> string -> 1.39086294174
Simplest for integer>0 (myconv) -> 0.463662147522
This should be faster but don't -> 1.7972369194

Testing numbers upto 1000000
----------------------------
str(object) -> string -> 1.48166298866
Simplest for integer>0 (myconv) -> 1.89623999596
This should be faster but don't -> 6.55253386497


Notes:

* It was faster for little numbers, and it seems that with
numbers growing gets worse.

*Without psyco, my native myconv is slower than str().

*Obviously, a simple list with the first 256 mixed with
str() (as I propoused on the previous thread breaks all
the stats! (With and without psyco..)

*The thrid test is using divmod() that i thought that would be
faster (i thought it could make only one division and get both
qoutient and remainder, without having to multiply..) but
was worse.

*Also tried that function using lists instead of strings,
but gaves worse results.

I include the source (with all the functions), so you can play with it.

See ya,
alejandro

PS: I want a faster divmod!

 

[Christopher T King]

*The thrid test is using divmod() that i thought that would be
faster (i thought it could make only one division and get both
qoutient and remainder, without having to multiply..) but
was worse.

PS: I want a faster divmod!

I was going to say that divmod was slower because it performs float
division instead of the integer division of // (which is true), but I'm
guessing the slowdown comes from the extra dictionary lookup needed for
divmod (unless this is somehow optimized away) instead. If that's indeed
true, then it seems that divmod doesn't adequately perform its intended
purpose, i.e. make use of the FPU's ability to divide and modulusify in
one step to gain speed.

 

[alejandro david weil]

I was going to say that divmod was slower because it performs float
division instead of the integer division of // (which is true), but I'm
guessing the slowdown comes from the extra dictionary lookup needed for
divmod (unless this is somehow optimized away) instead. If that's indeed

But both versions with and without divmod uses the same list lookup (
or there's something that i didn't see..).

true, then it seems that divmod doesn't adequately perform its intended
purpose, i.e. make use of the FPU's ability to divide and modulusify in
one step to gain speed.

If it's ability is to use fpu, it's ok that fails.. but, for integers it can
use standard i286 div instruction set (well I tried it only in x86, and also,
I think that Psyco works only there, so, it should be supposed from begining),
with does the same.

Saludos,
alejandro