Fwd: Re: Speed of str(positive_integer)..

[alejandro david weil]

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

Yes.
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.

Yes :-)

> > *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.

Exactly!
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
absolutly true..

> 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!
Alejandro
-- 
+ There is no dark side of the moon really. Matter of fact it's all dark.