On 09.10.2015 12:48, Thomas Voß wrote: > On Fri, Oct 9, 2015 at 12:43 PM, Michael Zanetti > <[email protected]> wrote: >> >> >> On 09.10.2015 11:49, Pete Woods wrote: >>> >>> >>> On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning >>> <[email protected] <mailto:[email protected]>> >>> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> >
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
