Speeding up Python applications
Gary Birkett has started a discussion on Talk to address ways of optimizing and speeding up Python applications. Looking for suggestions/ideas/code/methods for making python faster! [...] 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? Python has generally suffered performance-wise next to the bundled languages and toolkits used in Maemo, so any optimization will be welcome, especially given the mobile context of the platform (where battery life is so critical).
Qt's experimental versions and Maemo packages
PR1.2 has brought with it some large changes to Qt, its packaging which developers will need to observe for any of their own packages depending on it. One of the big changes PR1.2 brought us is official Qt support in the form of Q4.6 in the Nokia SDK and repositories. This change affects all applications depending on Qt currently in extras-devel. We had some talks with Qt/Nokia folks about Qt-related repository changes in Maemo 5 (triggered by aforementioned PR1.2 and potentially again later on by updates to Qt or related components). The biggest changes are the bundling of Qt 4.6 with PR1.2 (and its removal from Extras), and the streamlining of Qt 4.7 experimental packages in Extras-devel. See the article for a complete summary.
MeeGo Repository "Working Group" next steps
David Greaves is pushing discussion to refocus the MeeGo Repository Working Group issue on the MeeGo-dev mailing list. So it's been a while since the TSG meeting when the RWG was proposed [1];not a lot of discussion has arisen naturally (not surprising, there's not a lot for the community to build around yet). So maybe we can review what we think will be needed. The nebulous definition of "working groups" in MeeGo seems to have been a contributing factor in turning the Repository Working Group formation into an "issue". Hopefully these are just the growing pains of a new community and should be smoothed out in the coming weeks and months.
Using ccache 3.0 to speed up package building in Scratchbox
toninikkanen of Talk has posted an article on his blog outlining the use of ccache 3.0 to speed up package building in Scratchbox. Of course I knew that by default, Scratchbox uses ccache to speed up building. I had disabled it earlier since I suspected it caused some problems for me. But I wanted speed, so I enabled it again. After some more rebuilding I started thinking that it's not doing a very good job - it was still very slow. I checked the version of ccache supplied with Scratchbox - it was 2.3, from 2002. I checked and yes, there is a newer pre-release version from this year - 3.0pre0 and I set out to see if it would be faster. The newer version of ccache resulted in small performance increases over the 2.3 release included with Scratchbox, but the biggest improvement resulted from the removal of incompatible compiler options.
"Every time you scale a pixmap, God kills a kitten"
Robin Burchell has posted his findings of investigating why software rendering in Maemo 6/Harmattan/MeeGo/dui is so slow. His conclusion is that it can be a lot better, and he's posted a patch (and a gitorious merge request) for it to go upstream: Why was it slow? Well, it happened again. Not completely the same, of course, but this is a very similar issue to one I wrote about recently in Qt on Maemo. Something that a lot of developers, particularly ones working in higher level libraries or languages like C# or Qt forget from time to time is that image (or pixmap) scaling - in particular, smooth scaling - is generally nnoott a fast operation. The merge request had been denied by Armin Berres, citing the performance of SGX on "the target hardware" (presumably Nokia's OMAP-based devices). As of this writing, however, the request has been reopened, with a request for the patch to check for software rendering, as it isn't required when running with hardware acceleration.