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 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
