On 2015-10-09 13:20:35, Benjamin Zeller wrote: > 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 :).
I'll be doing this review. My target is to have it done around the middle of next week since there are a couple other reviews that'll need to be done before it. Benjamin knows all of this but I thought I'd mention it since others following this thread may not. Tyler > > 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
signature.asc
Description: Digital signature
-- 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
