On Mon, 14 Oct 2013 18:18:56 +0200 Jaroslaw Staniek <[email protected]> said:
> On 14 October 2013 17:34, Schaufler, Casey <[email protected]> wrote: > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of Jaroslaw > >> Staniek > >> Sent: Monday, October 14, 2013 8:22 AM > >> To: [email protected] > >> Cc: Schaufler, Casey; Jussi Laako; [email protected] > >> Subject: Re: [Dev] Tizen 3.0 proposal for applications launch > >> > >> On 14 October 2013 14:51, YOUNG IK CHO <[email protected]> > >> wrote: > >> > > >> > > The easy and, to my mind correct, solution is to let the kernel take > >> > > care of setting the security attributes and throw out the whole > >> > > "launcher" thing. I have *never* been presented evidence that > >> > > launchers actually improve performance in the final deployed > >> > > configuration. > >> > > But, that's a separate argument. > >> > > >> > Yes, it is a separete argument but I will just suggest the brief number. > >> > > >> > On the TIZEN 2.1 (previous version) mobile profile, it gives the huge > >> difference. My test app shows: > >> > > >> > - launch without preloading : 950msec > >> > > >> > - launch with proper preloading : 630msec > > > > Great! Numbers are very helpful. > > > >> > When my colleague analized the performance bottle neck, he found that > >> around 100~200msec is consumed on the dynamic loader. I know there are > >> several solutions like prelink or readlink but preloading works better. For > >> WebApp, wrt_launchpad performs pre-initialization heavily and it has much > >> more number than Core/Osp App in terms of performance gain. > >> > >> Interesting topic. > >> I'd like to add, in addition to web runtime, both Qt Quick and (real) EFL > >> apps benefit from preloading. Qt Quick has two engines in place > >> (JavaScript and QML) -- these, if preloaded and waiting for actual program > >> code, give great speedup. Preloading at this level was successfully used > >> in MeeGo Harmattan. > > > > But without numbers to back up these claims we can't > > use them to make decisions. 5 msec improvement would not > > be convincing, whereas 200 probably is. > > > >> In general, we get faster startups in any runtime that employs costly (in > >> terms of initialization) engines (web, JavaScript, QML, Python, whatever). > >> Of course that comes at the memory cost. > > > > The issue there is going to be how much the overhead of preloading > > impacts the overall system performance. I have not seen an analysis > > of that. > > Very true, you may get updated results (time, memory) in Qt Quick > department from Qt for Tizen contributors. Would NEXCOM VTC 7120-D1K > with a fresh installation of Qt for Tizen be ok? > > CC'd EFL's guys who expressed interest in the topic early this year > after publication of these analysis > [http://tolszak-dev.blogspot.com/2013/02/simple-qml-vs-efl-comparison.html]. > > That would leave checks the web runtime as a TODO. > > There are two observations, possibly obvious for most of you: > > - Private memory is the real memory cost of preloading multiple > instances of app runtimes. For example 80MB full (for all the > libraries) consumed for a single preloaded instance of app runtime, > but 70+10*n MB for n preloaded instances. So we fight for minimal size > of private memory so the cost of Shared/Rss/Pss can be hopefully > amortized. These are tests on x86 workstations but I believe similar > relationships are framework-specific and apply everywhere: > http://tolszak-dev.blogspot.com/2013/02/simple-qml-vs-efl-comparison.html#memoryConsumption > > - Delayed loading of any specific resources (even fonts, styles and > configuration), moving that out of the runtime engine, is indeed a > plus when we want to preload the instances of the runtime. indeed. efl actually defers pretty much anything it can - but there still is a cost. we're working to negate that cost further by adding cache server daemons... we have had one for a while but it hasn't been good enough to turn on by default. cserve2 is... getting ready to turn on by default. we now move a chunk of fonts and imagery to shared memory and ipc to a daemon with lots of shared tables etc. :) > - In addition, preloading feature can be rather easily switched off > globally or locally by eventual adopter of the Tizen platform if we > provide means for it. And it would be relatively transparent in a > sense that applications wouldn't notice functional differences. at least for efl if you "follow the conventions we document" we haver a normal main() entry point AND an extra elm_main() entry point,. the elm_main is split for use by preloading and elm already does/allows this as a dlopen preload mechanism. (so split out core app init that is generic between all apps to be before elm_main is called). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
