State of speeding up Python for full applications

[wxjmfauth at gmail.com]

Le jeudi 26 juin 2014 16:41:15 UTC+2, alister a écrit :
> On Wed, 25 Jun 2014 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