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.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Comments
8 responses to “Pitivi's startup time”
Why are those dependency checks mandatory? a distribution packager must be able to disable those checks and let the platform packaging tools do its work. Those checks only have a reason to exist when the application is being distributed ready to be used on any distribution, the equivalent of C programs dlopening libraries instead of linking directly to them in order create binaries for multiple distributions. A version of Pitivi installed from the distribution repositories do not need those checks
Dude… optimize for the case where it works 🙂
Awesome to see this meme catch on!
My thoughts on the UX: how often do the checks result in a problem that the user is (presumably) notified about? If the majority case is that the checks succeed (thanks to good packaging for example) then slowing down the launch every single time the app is launched simply to guard against that corner failure case makes little sense.
It sounds like the UI would be presented for at most 4 seconds before the results of the checks could be displayed to the user. I suspect that 4 seconds is not really enough time to get so entrenched in a project that seeing a failure message and losing their work due to non-working dependencies would have a high cost of recovery.
I’d suggest trying it out and seeing if the user could get into trouble (i.e. start work that is lost, cause a crash, etc) before the checks finish. I suspect your concerns may not translate into real-world problems for users.
Well yeah, ok, suppose we disable those checks entirely… as I said in my blog post, doing so removes about 4 seconds of a 21 seconds cold start and 1 second of a 5 seconds warm start. Food for thought. There is still something else making startup slow, and compared to that, the initial checks are “almost” nothing.
Now, those checks *did* fire off warnings multiple times when I was missing some runtime dependencies. I usually forget to install goocanvas and a couple of others. However, yes, it should be the packager’s job, so maybe this should be moved to the autogen/configure scripts (I have to wonder why they were not already in there instead) or only run if you are running pitivi directly from git…
Even then, I’m still stuck with a startup that I consider too slow for my tastes.
Offtopic: for the curious among you, I’m sometimes more annoyed by the startup time of gnome itself… https://bugzilla.gnome.org/show_bug.cgi?id=645756
Well, what about check running for first time? If deps are satisfied, then run without these checks after first time.
However, I wouldn’t worry about Pitivi startup time – it is complex app not IM client. It should run snappy, but launching time is tolerable as long you inform user what happens. Maybe offer those checks to be disabled optionally in user preferences.
Take a look at Blender if you havent already. Its written in python, is a very complex app with something of a superset of pitivis features yet starts in under 1s on a lappy sata, cold.
As for ux I rather see the window appear instantly and see it populated than nothing.
@liam:
Blender is not written in Python. Its main language is C++ (70% of the codebase), C (25%) and the remaining 5% is Python for the scripting engine.
Also, Blender has almost no external dependencies. It doesn’t have to load GTK, goocanvas, gstreamer, etc. But yes, it does start in 2 seconds cold on Krimson.