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

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

State of speeding up Python for full applications

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

Contents

  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

#73604 — State of speeding up Python for full applications

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.

[toc] | [next] | [standalone]

#73608

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.

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

#73620

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

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

#73652

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

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

#73625

I'm reposting my question with, I hope, better 
formatting:  


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.

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

#73626

On 26/06/2014 17:49, CM wrote:
> I'm reposting my question with, I hope, better
> formatting:
>
>
> 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.
>

Have you tried everything listed here 
https://wiki.python.org/moin/PythonSpeed/PerformanceTips ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [standalone]

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

csiph-web