Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #73608
| Newsgroups | comp.lang.python |
|---|---|
| Date | 2014-06-25 23:07 -0700 |
| References | <b97cdf98-6198-4375-9736-3a534a299a49@googlegroups.com> |
| Message-ID | <c6b3c6f2-0c83-4eb2-87e6-5eba2f389f00@googlegroups.com> (permalink) |
| Subject | Re: State of speeding up Python for full applications |
| From | wxjmfauth@gmail.com |
Le jeudi 26 juin 2014 05:54:29 UTC+2, CM a écrit :
> I occasionally hear about performance improvements for Python by various projects like psyco (now old), ShedSkin, Cython, PyPy, Nuitka, Numba, and probably many others. The benchmarks are out there, and they do make a difference, and sometimes a difference on par with C, from what I've heard.
>
>
>
> What I have never quite been able to get is the degree to which one can currently use these approaches to speed up a Python application that uses 3rd party libraries...and that the approaches will "just work" without the developer having to know C or really do a lot of difficult under-the-hood sort of work.
>
>
>
> For examples, and considering an application written for Python 2.7, say, and using a GUI toolkit, and a handful of 3rd party libraries:
>
>
>
> - Can you realistically package up the PyPy interpreter and have the app run faster with PyPy? And can the application be released as a single file executable if you use PyPy?
>
>
>
> - Can you compile it with Nuitka to C?
>
>
>
> I've had the (perhaps overly pessimistic) sense that you still *can't* do these things, because these projects only work on pure Python, or if they do work with other libraries, it's always described with major caveats that "I wouldn't try this in production" or "this is just a test" sort of thing, such as PyPy and wxPython.
>
>
>
> I'd love to know what's possible, since getting some even modest performance gains would probably make apps feels snappier in some cases, and yet I am not up for the job of the traditional advice about "re-writing those parts in C".
>
>
>
> Thanks.
==========
Very simple.
Use ascii. Python becomes an ascii product. Some
kind of an anti-unicode product.
>>> timeit.repeat("a = 'hundred'; 'x' in a")
[0.12480686986011946, 0.104518506819959, 0.1042400607146412]
>>> timeit.repeat("a = 'hundreoe'; 'x' in a")
[0.2405829487797, 0.21706272047752506, 0.21744435311692456]
>>>
Or use a more serious product, developed by
people who are understanding unicode and the
coding of the characters. (see the recent
discussion about "Internal representation of strings
and Micropython").
jmf
PS Even utf-8 products are doing much better.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
State of speeding up Python for full applications CM <cmpython@gmail.com> - 2014-06-25 20:54 -0700
Re: State of speeding up Python for full applications wxjmfauth@gmail.com - 2014-06-25 23:07 -0700
Re: State of speeding up Python for full applications alister <alister.nospam.ware@ntlworld.com> - 2014-06-26 14:41 +0000
Re: State of speeding up Python for full applications wxjmfauth@gmail.com - 2014-06-27 02:50 -0700
Re: State of speeding up Python for full applications CM <cmpython@gmail.com> - 2014-06-26 09:49 -0700
Re: State of speeding up Python for full applications Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-26 18:12 +0100
csiph-web