State of speeding up Python for full applications
wxjmfauth at gmail.com
wxjmfauth at gmail.com
Fri Jun 27 05:50:56 EDT 2014
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
More information about the Python-list
mailing list