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. Br, Michael
signature.asc
Description: OpenPGP 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