Performance of int/long in Python 3

Ian Kelly ian.g.kelly at gmail.com
Tue Apr 2 15:44:48 EDT 2013


On Tue, Apr 2, 2013 at 3:20 AM, jmfauth <wxjmfauth at gmail.com> wrote:
> It is somehow funny to see, the FSR "fails" precisely
> on problems Unicode will solve/handle, eg normalization or
> sorting [3].

Neither of these problems have anything to do with the FSR.  Can you
give us an example of normalization or sorting where Python 3.3 fails
and Python 3.2 does not?

> [3] I only test and tested these "chars" blindly with the help
> of the doc I have. Btw, when I test complicated "Arabic chars",
> I noticed, Py33 "crashes", it does not really crash, it get stucked
> in some king of infinite loop (or is it due to "timeit"?).

Without knowing what the actual test that you ran was, we have no way
of answering that.  Unless you give us more detail, my assumption
would be that the number of repetitions that you passed to timeit was
excessively large for the particular test case.

> [4] Am I the only one who test this kind of stuff?

No, you're just the only one who considers it important.
Micro-benchmarks like the ones you have been reporting are *useful*
when it comes to determining what operations can be better optimized,
but they are not *important* in and of themselves.  What is important
is that actual, real-world programs are not significantly slowed by
these kinds of optimizations.  Until you can demonstrate that real
programs are adversely affected by PEP 393, there is not in my opinion
any regression that is worth worrying over.



More information about the Python-list mailing list