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.
Here’s an introduction to the problem:
- An average Liferea user is expected to have hundreds of feeds and thousands of unread items (I have about 200 feeds and 2500 unread items). From discussions I’ve had, this is not considered excessive by Liferea standards.
- Liferea uses SQLite as a database for storing feed data into a single “liferea.db” file. Mine currently weighs 115 Mo in its vacuumed form. SQLite has this terrible tendency to suck because you need to vacuum (compact) it every once in a while or the performance degrades terribly. Firefox has the same problem.
- There also was ext4 as a suspect, although from all my tests on that matter in the 1.6 series, ext4 was definitely not the culprit. An ext3 partition had the same performance problems (or, at least, the same Liferea startup times).
Continue reading “Investigating Liferea's startup performance”
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:
- Kusanagi, my most powerful computer, equipped with a solid state drive and a Core2 Quad processor, 4 GB of RAM
- Kuze, a six years old Thinkpad T43p, with a conventional IDE hard drive and a Pentium M processor (single core), 2 GB of RAM
- Krimson, a modern laptop from 2009, with a conventional SATA hard drive and a “Pentium” SU4100 (dual core) processor, 3 GB of RAM
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.
So, I had noticed the phenomenon but never reported it thinking it was on purpose. Turns out it was not. Now, I did some benchmarking for Edward before and after his commits, and here are my results.
The benchmark is importing 74 clips (720P H.264 in a .mov container), measured with my stopwatch.
On a Dell Mini 9 netbook with an Atom N270 processor:
- before: 1 minute, 42 seconds
- after: 56 seconds
Continue reading “Import performance improvements”
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:
I talked about this problem with Wout when I first found out about it, and looked at various profiling tools (sysprof, oprofile, valgrind…), but could not find anything that was supposed to work with Python directly, let alone anything a mortal could use. Thus, we shrugged, and the problem sat there without further investigation, lacking the tools (and time) for that.
Tonight, I wanted to be the next Federico Mena Quintero, and so I tried it again. My first hypothesis was that Specto surely must be doing way too much work, or doing inefficient I/O in some way. I consider it unacceptable that a simple application like Specto does not launch instantly, instead taking as much time as a warm-start OpenOffice.
If you don’t know about software performance profiling, there is some truly awesome “hecho in Federico” material that you must see first. It is easy to understand and funny as hell:
Continue reading “Profiling Specto (and whole Python applications in general)”