Performance of int/long in Python 3

[Mark Lawrence]

On 01/04/2013 20:15, jmfauth wrote:
> ---------
>
>
> I'm not whining or and I'm not complaining (and never did).
> I always exposed facts.

The only fact I'm aware of is an edge case that is being addressed on 
the Python bug tracker, sorry I'm too lazy to look up the number again.

>
> I'm not especially interested in Python, I'm interested in
> Unicode.

So why do you keep harping on about the same old edge case?

>
> Usualy when I posted examples, there are confirmed.

The only thing you've ever posted are the same old boring micro 
benchmarks.  You never, ever comment on the memory savings that are IIRC 
extremely popular with the Django folks amongst others.  Neither do you 
comment on the fact that the unicode implementation in Python 3.3 is 
correct.  I can only assume that you prefer a fast but buggy 
implementation to a correct but slow one.  Except that in many cases the 
3.3 implementation is actually faster, so you conveniently ignore this.

>
>
> What I see is this (std "download-abled" Python's on Windows 7 (and
> other
> Windows/platforms/machines):
>
> Py32
>>>> import timeit
>>>> timeit.repeat("'a' * 1000 + 'ẞ'")
> [0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
>>>> timeit.repeat("'a' * 1000 + 'z'")
> [0.7105829560031083, 0.6904999426964764, 0.6938637184431968]
>
> Py33
> import timeit
> timeit.repeat("'a' * 1000 + 'ẞ'")
> [1.1484035160337613, 1.1233738895227505, 1.1215708962703874]
> timeit.repeat("'a' * 1000 + 'z'")
> [0.6640958193635527, 0.6469043692851528, 0.6458961423900007]
>
> I have systematically such a behaviour, in 99.99999% of my tests.

Always run on your micro benchmarks, never anything else.

> When there is something better, it is usually because something else
> (3.2/3.3) has been modified.
>
> I have my idea where this is coming from.

I know where this is coming from as it's been stated umpteen times on 
numerous threads.  As usual you simply ignore any facts that you feel 
like, particularly with respect to any real world use cases.

>
> Question: When it is claimed, that this has been tested,
> do you mean stringbench.py as proposed many times by Terry?
> (Thanks for an answer).

I find it amusing that you ask for an answer but refuse point blank to 
provide answers yourself.  I suspect that you've bitten off more than 
you can chew.

>
> jmf
>

-- 
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence