ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 09.10.2015 12:48, Thomas Voß wrote:
> On Fri, Oct 9, 2015 at 12:43 PM, Michael Zanetti
> <michael.zanetti@xxxxxxxxxxxxx> wrote:
>>
>>
>> On 09.10.2015 11:49, Pete Woods wrote:
>>>
>>>
>>> On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx
>>> <mailto:thomas.voss@xxxxxxxxxxxxx>> wrote:
>>>
>>>     On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning
>>>     <michi.henning@xxxxxxxxxxxxx <mailto:michi.henning@xxxxxxxxxxxxx>>
>>>     wrote:
>>>     >> you can indeed build apps in C++ if you want, but C++ is more complex to
>>>     >> understand and write (if you ever did a dynamic web page in your life
>>>     >> you likely know the basics of js). C++ needs a (cross) compile
>>>     >> environment set up while js means you can just dump a txt (well, .qml)
>>>     >> file in place and it just works. Doing C++ is just a lot more work and
>>>     >> while you can use C++ I think people find it easier to simply use js (I
>>>     >> surely do, i can write a ready made QML app including rolling the click
>>>     >> and uploading it to the store with a plain text editor within 20min, I
>>>     >> (personally) cant do that in C++)) ...
>>>     >
>>>     > Writing a dynamic web page in C++ is a bit like writing a neural network in COBOL. Don't.
>>>     >
>>>     > Would I write a device driver in JS? Probably not.
>>>     >
>>>     > Would I try to tighten a Phillips head screw with a nail file? Probably not either.
>>>     >
>>>     > I think you get the drift… :-)
>>>     >
>>>
>>>     +1 :)
>>>
>>>     Please note that qml and c++ components are happily mixed together
>>>     with QML/Qt. If there is a serious performance issue with using pure
>>>     QML,
>>>     falling back to C++ is always possible.
>>>
>>>
>>> Remember everyone, that Android apps launch pretty quickly, and they are
>>> Java based
>>> (and were only natively compiled with the release of Lollipop's ART).
>>>
>>> This is achieved through the use of a "Zygote" process and some clever
>>> copy-on-write
>>> page management (I *think* using special kernel patches). There is always a
>>> pre-warmed instance of the JVM ready, and it is forked each time a new
>>> app / service
>>> wants to launch. The page copy-on-write behaviour allows a new JVM
>>> instance to be
>>> spawned with almost no effort to the phone (you only copy the memory if
>>> you alter the
>>> Java runtime libs in some way, which is uncommon) and comes with large
>>> memory savings.
>>>
>>> The summary of what I'm saying is the old adage "there are no slow
>>> programming languages,
>>> only slow programs". I think a lot of our app launch speed troubles
>>> could be alleviated by
>>> employing the same techniques that Google does. The answer to
>>> performance issues
>>> is rarely to "switch programming language", assuming you're using a
>>> language that at
>>> least has a JIT compiler.
>>>
>>
>> FWIW, Benjamin is experimenting with MeeGo's applauncherd/booster, which
>> in principle does pretty much what you're describing. First tests do
>> suggest that it does improve the situation quite a bit. Details still to
>> be ironed out tho.
>>
> 
> where "details" are actual security issues that we have to solve prior
> to even start benchmarking :)

The main concerns of the security team have already been addressed
afaik. I might not have the full details tho.

> 
> The difficulty is _not_  in keeping a set of pre-warmed processes
> around to make app startup a rolling start.
> But implementing a solution that is both secure *and* provides
> significant improvements of app-startup time.
> 
> Cheers,
> 
>   Thomas
> 
>> Br,
>> Michael
>>
>>
>> --
>> 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
>>
>

Attachment: signature.asc
Description: OpenPGP digital signature