Could we somewhere find this result? I'm very excited because of this. :) 2015-10-09 13:20 GMT+02:00 Benjamin Zeller <benjamin.zel...@canonical.com>:
> Am 09.10.2015 um 12:56 schrieb Thomas Voß: > >> On Fri, Oct 9, 2015 at 12:55 PM, Michael Zanetti >> <michael.zane...@canonical.com> wrote: >> >>> >>> On 09.10.2015 12:48, Thomas Voß wrote: >>> >>>> On Fri, Oct 9, 2015 at 12:43 PM, Michael Zanetti >>>> <michael.zane...@canonical.com> wrote: >>>> >>>>> >>>>> On 09.10.2015 11:49, Pete Woods wrote: >>>>> >>>>>> >>>>>> On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß < >>>>>> thomas.v...@canonical.com >>>>>> <mailto:thomas.v...@canonical.com>> wrote: >>>>>> >>>>>> On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning >>>>>> <michi.henn...@canonical.com <mailto:michi.henn...@canonical.com >>>>>> >> >>>>>> 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 main concern was that using mapplauncherd would weaken ASLR, however > we managed to work around that issue and our profiling was showing pretty > good > results. > > Now we are waiting for the security team to review what we have. Only > after we > got a OK from them we can release something :). > > Cheers > > Benjamin > > Even better then, I will see if I can get Jamie to respond to this thread. >> >> Cheers, >> >> Thomas >> >> 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@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp