Thanks, that would be great. :) 2015-10-09 13:31 GMT+02:00 Benjamin Zeller <benjamin.zel...@canonical.com>:
> Am 09.10.2015 um 13:28 schrieb Richard Somlói: > > Could we somewhere find this result? I'm very excited because of this. :) > > In case we get the OK from security (please keep in mind that still could > stop the whole thing), > we will write a big and nice blogpost about it :). With figures and > barcharts ;) > > > 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 > >
-- 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
