Fwd: Re: Speed of str(positive_integer)..
alejandro david weil
aweil at mail.ru
Tue Jun 29 05:17:37 CEST 2004
On Mon June 28 2004 21:33, you wrote:
> > *Without psyco, my native myconv is slower than str().
> I suspect that the psyco version is (under the hood) doing more-or-less the
> same thing as the C implementation of str() that you're testing against.
> For small numbers your one beats it because you don't have to do all the
> other work that str() does (negatives, non-integers, etc), but as the
But negatives represents not much more work.
And, I mean, with that example, that one especific function,
like that that I show, may give good results as those.
Of course, a good and standard function is more secure, better
tested etc. but if looking for and speed optimization..
(anyway i like that standard functions be as fast as possible).
And, for optimize that, a table is better of anything (of course,
knowing that, for example, we want only to convert numbers
from 0 to 256.. etc..)
Also, Psyco makes str() work faster.
I should check, when have some time, how is str() implemented.
> numbers become larger these are less relevant and you get the expected
> result of implemented-in-C just beating implemented-in-Python-plus-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.
> 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
(I'm not sure that that is better but i think that it
should (at least, in assembler (and for integers)))
> (with Python 2.3.4). I suppose this is the penalty for the additional work
> that divmod does with checking signs and so on.
I'm unsure of how many more things has to do divmod.
Anyway, if it's implemented in C it couldn't (i think) use the
div from assembler that leaves quotient and remainder on
different registers. I mean, it should be specially implemented. :-(
> > *Also tried that function using lists instead of strings,
> > but gaves worse results.
> At least part of this could be due to the fact that it's quite a bit slower
> (about 2x, with Python 2.3.4, here) to create an empty list than create an
> empty string (which each version does, respectively).
> I believe, also (and timeit seems to agree) that the append/join idiom is
> only better for long strings - here there are up to 7 strings of one
> character each, in which case simple += is better.
That's one of the things that I wanted to see and show. People
said that using lists were faster and the only improvement that
could made on the "can you make it faster" thread.. but that's not
> BTW, the timeit module is useful for doing these sorts of things.
Ouh.. i didn't know the existence of it. :-)
I'll check how to use it. Also, it would be nice a graphic showing
how, for example, with longer strings one function goes better
than other.. right? is that possible?
Thanks for your answer!
+ There is no dark side of the moon really. Matter of fact it's all dark.
More information about the Python-list