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). -- Mailing list: https://launchpad.net/~unity-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-dev More help : https://help.launchpad.net/ListHelp
