unity-dev team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

On 05/23/2012 10:48 AM, Gord Allott wrote:
> On Wed 23 May 2012 08:31:16 BST, 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
>>
> Hum interesting, though UBus was initally designed so that messages 
> shouldn't have a higher priority than draws in the main loop, Obviously 
> there is a need for that sometimes though. maybe we need the option of 
> setting your priority when sending a message for instances like dash 
> activation.
>
> I don't think it makes sense to switch all ubus messages to a default 
> priority though.

Indeed, that's why I said it isn't a "proper" fix. But it could be
fairly non-trivial to support multiple priorities within UBus itself,
perhaps just adding a simple synchronous dispatch would do? (that way we
could manually register a GSource with any priority we need and then
just use the synchronous dispatch of UBus).