Making Python faster (for fmms initially)
 

Hi,
looking for suggestions/ideas/code/methods for making python faster!

in #maemo irc, x-fade remembered about a pylauncher project, but does not know of its active status in fremantle:
http://pylauncher.garage.maemo.org/

what other things can we do to effectively speed up python
simple things, suggestions metrics etc
does removing the comments make a noticable difference to script runtime?
mini ad-hoc brainstorming session..


================================================== ====
Update, added wiki page results

A couple of weeks later and after much discussion and testing we have a fairly decent set of guidelines and best practices \o/

Performance_Considerations_for_Python_Apps

thanks to epage for the excellent wiki writeup :)

Re: Making Python faster (for fmms initially)
 

Is this possible on ARM:

http://psyco.sourceforge.net/

Re: Making Python faster (for fmms initially)
 

I'm not a developer so not 100% sure, but this thread is somewhat similar/hopefully helpful.

http://talk.maemo.org/showthread.php?t=47850

Edit: just noticed that the other thread is only for improving the inital startup times and not in general. My bad

Re: Making Python faster (for fmms initially)
 

don't apologise - its all part of the same thing!

Re: Making Python faster (for fmms initially)
 

Interesting post....... I feel i may be able to provide a few tests to back up issues....

Healthcheck currently has about 300 redundant lines of code (Comments + Blank lines) probably 25% of the total.

I'll run a version of it without all of those and compare load times :D

Re: Making Python faster (for fmms initially)
 

@lcuk
My damn N900 ate the smiley for some reason & made me look like a sad panda :p

Anyways good to see the overall scheme includes start up improvements too.

Re: Making Python faster (for fmms initially)
 

The import method of not importing everything has some postive impacts, though probably small.

- reduce startup time
- reduces code size as your code no longer has to refer to the base class. ie qtcore.qrectangle becomes just qrectangle
- not sure if references become a bit faster internally, but feels right to me.

I would also use constants where possible rather than have them values recalculated, as is often the case in code.

given most heavy lifting code is done inside the libraries like qt I,m not sure python is much slower, and if you ae not using libraries why not especially given the richness of them. of course YMMV

Re: Making Python faster (for fmms initially)
 

from irc:
that sounds like an improvement right off the bat!

Re: Making Python faster (for fmms initially)
 

When we talk about making Python "faster" do we mean:
(a) perceptionally faster (e.g. time to reach first screen)
(b) execution speed

Re: Making Python faster (for fmms initially)
 

The concept, yes, but isn't really popular on ARM as it uses quite a bit of memory, which is often not in abundance in the embedded world. There were pioneering attempts on ARM (not the 'real' psyco, that one is i386+ only), but I have no idea what phase did they get to.

Also, for tricks using preloaders: Please consider what that does to memory - keeping GTK and/or QT bindings in there is quite a burden, think it through before you commit to such a thing.