Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #40075 > unrolled thread

Python Speed

Back to article view | Back to comp.lang.python

Contents

  Python Speed Terry Reedy <tjreedy@udel.edu> - 2013-02-27 17:24 -0500
    Re: Python Speed jmfauth <wxjmfauth@gmail.com> - 2013-02-27 23:40 -0800
      Re: Python Speed Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-28 08:09 +0000

#40075 — Python Speed

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

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#40120

On 27 fév, 23:24, Terry Reedy <tjre...@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

[toc] | [prev] | [next] | [standalone]

#40122

On Wed, 27 Feb 2013 23:40:22 -0800, jmfauth wrote:

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



-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web