unity-dev team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

On 05/23/2012 11:06 AM, Mikkel Kamstrup Erlandsen wrote:
> 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).
>

Yep, I saw that in multiple glib-based apps I was working on - reusing a
source makes quite a difference especially on high-res timers (it's
quite noticeable even on ones with 40ms timeout).