Python Speed

[jmfauth]

On 27 fév, 23:24, Terry Reedy <tjre... at udel.edu> wrote:
> 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 Jan Reedy

---------

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