[Dev] Tizen 3.0 proposal for applications launch

Jaroslaw Staniek staniek at kde.org
Mon Oct 14 15:21:34 GMT 2013


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

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.

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