unity-dev team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxxxxxx>]

On 05/23/2012 09:31 AM, Michal Hruby wrote:
> 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?

One thing we might wanna look at is how many GSources we create. I read 
somewhere that someone saved a lot of time changing to having his 
callbacks share a single GSource, instead of creating and attaching a 
gajillion sources. This is not just for UBus of course, but in anything 
perf critical (nux/unity/compiz jumps to mind).

Cheers,
Mikkel