Python Speed

[Terry Reedy]

Some are building, some are destroying.

We are still waiting for you to help build a better 3.3+, instead of
trying to 'destroy' it with mostly irrelevant cherry-picked benchmarks.

Py33[0.2573893570572636, 0.24261832285651508, 0.24259548003601594]

On my win system, I get a lower time for this:
[0.16579443757208878, 0.1475787649924598, 0.14970205670637426]

Py323
timeit.repeat("{1:'abc需'}")
[0.11000708521282831, 0.0994753634273593, 0.09901023634051853]

While I get the same time for 3.2.3.
[0.11759353304428544, 0.09482448029000068, 0.09532802044164157]

It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in
microseconds, so few programs will ever notice the difference.

In the meanwhile ... Effort was put into reducing startup time for 3.3
by making sure that every module imported during startup actual needed
to be imported, and into speeding up imports.

The startup process is getting a deeper inspection for 3.4
http://python.org/dev/peps/pep-0432/
'Simplifying the CPython startup sequence'
with some expectation for further speedup.

Also, a real-world benchmark project has been established.
http://speed.python.org/
Some work has already been done to port benchmarks to 3.x, but I suspect
there is more to do and more volunteers needed.

 

[jmfauth]

On 2/27/2013 3:21 AM, jmfauth hijacked yet another thread:
 > Some are building, some are destroying.

We are still waiting for you to help build a better 3.3+, instead of
trying to 'destroy' it with mostly irrelevant cherry-picked benchmarks.

 > Py33
 >>>> timeit.repeat("{1:'abc需'}")
 > [0.2573893570572636, 0.24261832285651508, 0.24259548003601594]

On my win system, I get a lower time for this:
[0.16579443757208878, 0.1475787649924598, 0.14970205670637426]

 > Py323
 > timeit.repeat("{1:'abc需'}")
 > [0.11000708521282831, 0.0994753634273593, 0.09901023634051853]

While I get the same time for 3.2.3.
[0.11759353304428544, 0.09482448029000068, 0.09532802044164157]

It seems that something about Jim's machine does not like 3.3.
*nix will probably see even less of a difference. Times are in
microseconds, so few programs will ever notice the difference.

In the meanwhile ... Effort was put into reducing startup time for 3.3
by making sure that every module imported during startup actual needed
to be imported, and into speeding up imports.

The startup process is getting a deeper inspection for 3.4http://python.org/dev/peps/pep-0432/
'Simplifying the CPython startup sequence'
with some expectation for further speedup.

Also, a real-world benchmark project has been established.http://speed.python.org/
Some work has already been done to port benchmarks to 3.x, but I suspect
there is more to do and more volunteers needed.

---------

Terry,

As long as you are attempting to work with a "composite" scheme
not working with a unique set of characters, not only it will
not work (properly/with efficiency), it can not work.

This not even a unicode problem. This is true for every coding
scheme. That's why we have, today, all these coding schemes, "coding
scheme": == "set of characters"; != "set of encoded characters".

jmf

 

[Steven D'Aprano]

As long as you are attempting to work with a "composite" scheme not
working with a unique set of characters, not only it will not work
(properly/with efficiency), it can not work.

What's a "composite scheme"?

This not even a unicode problem. This is true for every coding scheme.
That's why we have, today, all these coding schemes, "coding scheme": ==
"set of characters"; != "set of encoded characters".

This doesn't make any sense to me. What do you think this means?

Oh, and the actual reason we have "all these coding schemes" is for
historical reasons. Just about every PC manufacturer invented their own
encoding for whatever characters they cared about.