[Dev] Tizen 3.0 proposal for applications launch

Jaroslaw Staniek staniek at kde.org
Mon Oct 14 16:18:56 GMT 2013

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

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:

- 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.

- 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.

regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt for Tizen | http://qt-project.org/wiki/Tizen
 Qt Certified Specialist | http://www.linkedin.com/in/jstaniek

More information about the Dev mailing list