[Dev] Tizen 3.0 proposal for applications launch

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Oct 16 04:47:35 GMT 2013


On Mon, 14 Oct 2013 18:18:56 +0200 Jaroslaw Staniek <staniek at kde.org> said:

> On 14 October 2013 17:34, Schaufler, Casey <casey.schaufler at intel.com> wrote:
> >> -----Original Message-----
> >> From: kexipl at gmail.com [mailto:kexipl at gmail.com] On Behalf Of Jaroslaw
> >> Staniek
> >> Sent: Monday, October 14, 2013 8:22 AM
> >> To: youngik.cho at samsung.com
> >> Cc: Schaufler, Casey; Jussi Laako; dev at lists.tizen.org
> >> Subject: Re: [Dev] Tizen 3.0 proposal for applications launch
> >>
> >> On 14 October 2013 14:51, YOUNG IK CHO <youngik.cho at samsung.com>
> >> 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)    raster at rasterman.com



More information about the Dev mailing list