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
I won’t bore you with the details/show you my wall of numbers and measurements, I’ll summarize everything by this pretty graph comparing before/after:
Startup times (in seconds, until the user interface shows up) were measured with a stopwatch, so expect a margin of error of 0.3-0.5 seconds, but my measurements are pretty reliable (having done them multiple times).
Cold startup times are done by flushing the kernel caches (echo 3 > /proc/sys/vm/drop_caches).
I thought Benjamin’s idea of launching gnome-control-center afterwards (to simulate real-world cold startup times) was clever, and so I re-ran all my benchmarks with it. I’ll refer to those as “lukewarm” startup times (maybe someday I’ll be known as the guy who was crazy enough to coin that term). I do think the best indicator of real-world “frustration-inducing” startup times would probably be the “lukewarm” values (rather than an absolute cold start or a warm start).
In the 0.14.91 pitivi pre-release, we shaved off roughly 2 seconds of startup time compared to 0.14 (thanks to Alexandru’s hard work). As you can see, there’s still room for improvement, but optimizing the startup times of a complex application with many checks and dependencies is hard.
I willingly left some data out (from experimental optimization branches and such) to keep things simple (and accumulated gains of 0.3 seconds don’t make that much of a difference at this stage), but I’m guessing that one of the culprits is the fact that we do a lot of stuff in pitivi/check.py on startup (disabling checks entirely, on Kuze, shaves off 4 seconds cold/lukewarm and 1 second warm). The thing is, those checks are necessary to ensure that pitivi has at least the minimum to actually work properly (though maybe some of those checks could be reevaluated)… and what is the point of showing the user interface quickly if you can’t actually run the app because you don’t have cairo, the proper version of gtk, goocanvas, gnonlin, and so on?
One could argue that we should simply show the main window, then run the checks and present the user with a dialog listing everything that’s wrong… but how is the user experience expected to be in that case?
But check.py may not be the only thing. We may be doing something really stupid. Take a look at my bug report and help us investigate this. I have a nice cProfile output with its pretty graph telling you where most of the time is spent during startup.
Latest posts by nekohayo (see all)
- Defence against the Dark Arts involves controlling your hardware - March 18, 2017
- Reviewing the Librem 15 - January 10, 2017
- Renommer un périphérique audio avec PulseAudio - January 3, 2017