On Mon, 14 Mar 2011 16:34:09 +0100 Carsten Munk <[email protected]> wrote:
> 2011/3/14 <[email protected]>: > > Hi, > > > > I was taking a quick look at the apps on MeeGo images. It seems > > that none of the current apps utilize launcher (booster) for > > improving the startup time. Previously, I've seen that using > > launcher can improve startup time of meego touch based apps 1-2s, I > > do not know yet how much the improvement would be on N900. There is > > also no memory penalty in using launcher, it may even save some > > memory. Prestarting is different thing. > > > > Please see: http://apidocs.meego.com/git-tip/mtf/launcher.html on > > more info about the launcher. > > > > BTW; This might be EasyFix improvement in some of the app cases, > > where apps code is simple. > > > > I think that it is more than an EasyFix - there's the 'catch' the > applications are made such that they derive their 'main' class from > MAppplication such as DialerApplication. And booster can't instiatiate > subclasses. > > We had a conversation regarding this at some point in an e-mail > exchange, Arun has been working with it and Pertti Kellomäki and had > this to say: > > "I'm afraid that if you inherit from MApplication, then you cannot > really use the meegotouch booster. The booster process creates an > MApplication, and there is no way to turn it into an SmsApplication > after the fact. My hunch is that the other problems you are seeing may > be related to this. > > That said, you could still get some benefits (e.g. shared library > loading) by using the qt booster. Using the booster also helps in > saving system memory by sharing memory copy-on-write between > processes." (Pertti) It was also my understanding that the booster/pre-launch combo was also really only of benifit to ARM, since the IA platform can efficiently use PMIC ... though I confess this is not an area of expertise for me. My point is, if it helps ARM but hurts IA, then it's a non-starter. Likewise, if it helps IA and hurts ARM, I suspect the same is true. We really need to find appropriate mechanisms that work well across architectures, or clear documentation on how to re-write apps in a manner that allows them to be conditionally compiled per arch, if it makes sense to do so. > As well as Shane mentioning the change from DialerApplication to a > DialerContext of sorts would be quite an invasive change to the > current code and possibly conflict with efforts to make Dialer > headless. Lets take another look at this once Arun and Michael sort out the current "headless" re-architecture that is currently underway,OK? Shane... _______________________________________________ MeeGo-handset mailing list [email protected] http://lists.meego.com/listinfo/meego-handset
