Making Python faster (for fmms initially)

[lcuk]

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

[Bundyo]

Is this possible on ARM:

http://psyco.sourceforge.net/

[un-named_user]

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

[lcuk]

Originally Posted by un-named_user

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.

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

[noobmonkey]

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

[un-named_user]

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

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

[mikec]

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

[lcuk]

from irc:

<frals> right fixed the gtk import now anyway so the daemon doesnt import it, not sure about startup time but its taking 13MB less in memory :P

that sounds like an improvement right off the bat!

[johnel]

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

[attila77]

Originally Posted by Bundyo

Is this possible on ARM:

http://psyco.sourceforge.net/

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.