State of speeding up Python for full applications

Fri Jun 27 05:50:56 EDT 2014

Le jeudi 26 juin 2014 16:41:15 UTC+2, alister a écrit :
> On 2014年6月25日 20:54:29 -0700, CM wrote:
>>>> > 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.
>>>> 1st find out where the true bottlenecks in your code only & only optimise 
>> those parts they absolutely need it
>> Rules for optimisation:-
>> 1: Dont
>> 2: (for advanced users only) Not Yet
>>>> 2nd either move away from Google groups & use the mailing list/newsgroup 
>> or read posts regarding how to clean up the mess it makes, otherwise the 
>> only replies you are likely to see will be from the resident Unicode 
>> expert complaining about strings containing characters that can be 
>> represented by a single bite (ascii) performing faster than those that 
>> contain higher Unicode characters.
>>>>>>>> -- 
>> How do I type "for i in *.dvi do xdvi $i done" in a GUI?
>> 	-- Discussion in comp.os.linux.misc on the intuitiveness of 
>> interfaces

%%%%%%%%
- Let me repeat again. I'm not complaining, I'm exposing
facts.
- Serious unicode tools are not suffering from this kind of
issues.
- It's only an (one) illustration of a bad unicode handling.
- Not only this, I'm able to explain it, and I hope, you
do not mind if I'm using Python as pefect example of a
bad unicode implementation (it's wrong by design).
- I'm the first to recognize that hobbyist tools have
the right to be and/or to stay hobbyist tools. At "unicode
time", unicode is an excellent revelator.
---
On
> "for i in *.dvi do xdvi $i done"

Curiously, "xdvipdfmx" (to be short) seems to
handle unicode very well and correctly. ;-)
jmf