Last week, Lars Lindner provided us with an early christmas gift when he announced that a new stable release of our beloved feed reader was now available. First, I would like to applaud him for his continued efforts over the years in maintaining this handy and high quality application. Many users like me have been patiently waiting for the 1.8 release in the hope that it would finally solve the infamous performance problems of the 1.4 and 1.6 series. However, while I can’t speak of the performance once the app is launched, the startup performance has not met my expectations (in some cases, it has regressed). This blog post is intended to share my findings (which I discussed with Lars) and to invite you to comment on possible solutions.
So, since it seems everybody’s been talking about startup time these days, I’ll admit I tend to secretly obsess over that too. Well, it’s not so secret given that I’ve blogged about profiling work on Specto and PiTiVi before… anyway.
I believe you should provide your developers with the fastest computers to do the development, and five years old computers to do the testing. I therefore do my benchmarks on three computers: Continue reading “Pitivi’s startup time”
Sometimes I think developers should use netbooks as their testing machines. Then they would be hit by performance bottlenecks in much more obvious ways :)
This morning, Ed pushed a commit that limits the thumbnail size to 96×96 (previously unlimited) in PiTiVi’s master branch. What this means is that previously, each time you imported a clip into your project, PiTiVi was creating a full-resolution PNG image and storing it into /tmp. Not a good idea. Especially if you work with 720P HD files like me.
A few months ago (when we still thought we were about to release 0.3 “real soon now” ;), I noticed that Specto is noticeably slow to start up, even on warm starts (when it is not the first time you launch it). It always takes at least 6 seconds to paint the list of watches and start refreshing them. During that time, there is a notably high CPU usage spike (surprisingly, no noticeable hard drive I/O), as shown below: