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. - 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
