unity-dev team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

Hey everyone,

as I already discussed with some of you, I was looking into optimizing
parts of Unity some time ago, with the specific goal of making the dash
open as fast as possible.

I already opened https://bugs.launchpad.net/nux/+bug/994884 fixing which
should help with the initial open, but I experimented further and one of
the things that I tried was to increase priority of UBus message
processing (IDLE -> DEFAULT), afterwards I measured the time delta
between LauncherController::SendHomeActivationRequest and
DashView::DrawContent (ie time between unity getting the Super keypress
event and it painting the dash), and the results were quite interesting:

Trunk:
- idle system avg: 126ms
- system under load avg: 289ms

Increased UBus prio:
- idle system avg: 103ms
- system under load avg: 160ms

So a speedup of 20-45%, which is pretty nice for a one liner... That
said I'm not suggesting that this is a correct fix, but it seems like
we're not looking at the bigger picture of main loop interactions. For
example GTK makes sure that geometry changes are always processed with
higher priority than draws, do we do that? (it would surely help with
the bug mentioned above).

Thoughts how to improve the situation? Comments?

Cheers,
Michal