Investigating Liferea’s startup performance

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.

Continue reading “Investigating Liferea’s startup performance”

Pitivi’s startup time

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”

Negotiating Performance

If you do more than basic video editing, you may have experienced those infamous “not-negotiated” errors, one of the most annoying current issues in pitivi. Users run into not-negotiated errors when there are transitions, gaps in the timeline, and effects that require compositing (such as the “alpha” filter) fail to work properly. Sometimes, if you keep changing the timeline, things magically fix themselves (when it goes back to using whatever format it was using before it errored out).

Stability vs performance

Continue reading “Negotiating Performance”

Improving project loading performance

When you load a project in PiTiVi, importing the clips into the “media library” (also known internally as the “source list”) is pretty fast, but inserting them in the timeline is painfully slow. So I whipped out my torture test project and spent some time profiling what’s going on using Python’s cProfile module (I talked about it before, but see also this well-written page from the GTG folks).

The findings were interesting. Graphically, we end up with something like this:

Continue reading “Improving project loading performance”

Améliorer les performances de GTG

Pour les fans de la technique GTD de David Allen, Getting Things GNOME! est une révélation, un logiciel qui rend «sans douleur» l’ajout et la gestion de tâches. Je considère les fonctionnalités suivantes comme étant celles qui démarquent GTG des autres applications:

  1. La capacité d’utiliser un langage naturel, tel que “defer:20100224” ou “due:vendredi” (et on peut quand même utiliser les mots clés en anglais, c’est généralement plus court: “due:friday”);
  2. La capacité de «reporter» une tâche;
  3. Un mode «vue de travail», qui fait en sorte de masquer toutes les tâches reportées, qui ne peuvent pas encore être commencées ou qui dépendent d’autres tâches. Dans mon cas, c’est la différence entre avoir 130 tâches devant les yeux et en avoir 30. C’est fantastique, ce que ça permet et termes de «focus»;
  4. Un système de «tags», avec la possibilité d’exclure certains tags de la «vue de travail»;
  5. Un bouton «Marquer comme fait» qui est, naturellement, jouissif.

Continue reading “Améliorer les performances de GTG”

Performance vs usability

I had an idea to make Evolution display more human-readable/stuff-I-care-about-only sender information, but it was scrapped. It is sad when you hit technical roadblocks in technology (here, performance considerations) that trump usability (well, that and the fact that the devs were not too enthusiastic about the idea to begin with).

Import performance improvements

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.

Continue reading “Import performance improvements”

Improved Specto startup times

After my post on profiling Specto’s startup, Wout Clymans put on his Hero Hacker Hat and fixed the major problem that was causing Specto to do too much work for nothing. Now, Specto starts in 2 seconds instead of 10 seconds.

What happened there? Well, for making sure that we are using the same “internal” watch list as the actual watches in ~/.config/specto/watches.list (if I’m not mistaken), Specto loaded the file each time and parsed it. The problem is that this is useful (not even 100% sure about it) only when you manually ask Specto to refresh, not during startup, where the watch list is obviously up to date. What Wout did to fix the problem is create a special parameter that makes those method avoid opening and parsing the watch list all the time on startup.

Continue reading “Improved Specto startup times”

Profiling Specto (and whole Python applications in general)

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:

Continue reading “Profiling Specto (and whole Python applications in general)”

Rhythmbox: sois patient

  • Ma librairie musicale: 11200 morceaux
  • Démarrage à chaud de Rhythmbox si on le laisse démarrer «tranquillement» (sans le forcer à jouer de la musique immédiatement): 13 secondes jusqu’au moment où il n’y a plus de grattage de disque dur et de barre de progression.
  • Démarrage à chaud de Rhythmbox si on lui demande de jouer immédiatement une webradio: 20 secondes.
  • Démarrage à chaud de Rhythmbox si on lui demande de jouer immédiatement un morceau local: 26 secondes.

J’ai ouvert un bug détaillant ma méthodologie et mes résultats. Si quelqu’un a une idée de ce qui se passe, je serais curieux de l’entendre.

Continue reading “Rhythmbox: sois patient”

Readahead personnalisé pour réduire le temps de login

Je suis un maniaque assoiffé de performances. J’ai lu des discussions, wikis, écoutés toutes les conférences d’optimisation de gnome, et j’ai peut-être bloggé plusieurs fois à propos de mes nombreuses tentatives pour presser chaque seconde de vitesse de login possible.

Mais depuis six mois, j’étais un peu déprimé de constater que peu importe ce que je faisais, pas moyen, sur aucun de mes ordinateurs, d’abaisser le temps de login «à froid» en bas du seuil des 30 secondes. Qu’est-il arrivé aux belles promesses de «gnome devrait se connecter en trois secondes et c’est tout»? Je ne sais pas, et y penser m’attriste.

Continue reading “Readahead personnalisé pour réduire le temps de login”

Régression de performances de login avec compiz fusion

Mon ordinateur portatif nécessitait 45 secondes pour le processus de «login» à partir d’un démarrage «à froid» de l’ordinateur. C’est indécent me dis-je, «c’est des performances que j’attendrais d’une vieille installation Windows XP infectée».

Puis j’ai désactivé compiz (activé par défaut dans ubuntu 7.10), redémarré l’ordinateur pour refaire mon chronométrage à froid, et cette fois le processus a nécessité 30 secondes. Compiz, tel que livré avec ubuntu 7.10 alpha 5, est donc un frein de performances de 50% !

Continue reading “Régression de performances de login avec compiz fusion”