← Back to team overview

ubuntu-phone team mailing list archive

Re: mapplauncher

 

Am 28.07.2015 um 22:27 schrieb Juhapekka Piiroinen:
Hi all :)
Hey

Slightly off-topic, but could bring value to the discussion concerning
the app start-up times. Have you looked into the QML Compiler [1]
which would remove the delays due to the runtime compiling. Someone
could look which parts of the private Qt headers are required and then
could do something similar, or just other could just contribute to the
project.

We are looking into using the qml-compiler from Digia atm. The one
you posted is kind of already used. The QML cache currently used on the
devices is based on those compiler patches.


[1] https://github.com/qmlc/qmlc


Cheers,
JP

On Tue, Jul 28, 2015 at 7:45 PM, Benjamin Zeller
<benjamin.zeller@xxxxxxxxxxxxx> wrote:
Am 28.07.2015 um 18:15 schrieb Rodney Dawes:

On Tue, 2015-07-28 at 18:01 +0300, Zoltán Balogh wrote:

I know that there are security concerns about how the mapplauncherd
works.  After talking to the main developer (w00t on freenode) and
reviewing the code I have learned what the mapplaucnher is doing [7]

If you have any experience or opinion about the topic please bring it up :)

This idea looks very promising and piling off seconds from the app
starts is something we all are interest, but obviously not for the price
of compromising our platform's security.

What are the real benefits of doing this? If this is to improve app
startup speed, is there any significant and concrete data showing that a
perceivable and significant increase in performance is made from this,
compared against the normal execution of various types of apps, not just
pure qml apps being run via qmlscene? Do we even have concrete profiling
data showing where exactly the slowness is for all these various types
of applications?

This seems like a very over-engineered and complex way to work around an
otherwise simple (albeit pervasive) problem.




The problem with the small application starting is simply the time QML
requires to be compiled first and then the time the components need to be
created.
All this is then loaded into a internal cache for the next time a component
is reused.

Our current solution (the QML cache) just removes the need to reparse the
components. But the first time startup experience is bad and preloading can
scrape off another second or more.

The preloader can also create components instead of just parsing them. Which
adds another
performance boost compared to the QML cache.

In the first mail Zoltan has linked some profiling on applauncherd vs qml
cache vs no cache.

--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp




References