ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #16142
Re: Why js not c++?
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.zanetti@xxxxxxxxxxxxx> wrote:
> >>
> >>On 09.10.2015 12:48, Thomas Voß wrote:
> >>>On Fri, Oct 9, 2015 at 12:43 PM, Michael Zanetti
> >>><michael.zanetti@xxxxxxxxxxxxx> wrote:
> >>>>
> >>>>On 09.10.2015 11:49, Pete Woods wrote:
> >>>>>
> >>>>>On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx
> >>>>><mailto:thomas.voss@xxxxxxxxxxxxx>> wrote:
> >>>>>
> >>>>> On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning
> >>>>> <michi.henning@xxxxxxxxxxxxx <mailto:michi.henning@xxxxxxxxxxxxx>>
> >>>>> 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@xxxxxxxxxxxxxxxxxxx
> >>>>Unsubscribe : https://launchpad.net/~ubuntu-phone
> >>>>More help : https://help.launchpad.net/ListHelp
> >>>>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help : https://help.launchpad.net/ListHelp
Attachment:
signature.asc
Description: Digital signature
Follow ups
References
-
Why js not c++?
From: Grak Pal, 2015-10-08
-
Re: Why js not c++?
From: Oliver Grawert, 2015-10-08
-
Re: Why js not c++?
From: Michi Henning, 2015-10-08
-
Re: Why js not c++?
From: Thomas Voß, 2015-10-08
-
Re: Why js not c++?
From: Pete Woods, 2015-10-09
-
Re: Why js not c++?
From: Michael Zanetti, 2015-10-09
-
Re: Why js not c++?
From: Thomas Voß, 2015-10-09
-
Re: Why js not c++?
From: Michael Zanetti, 2015-10-09
-
Re: Why js not c++?
From: Thomas Voß, 2015-10-09
-
Re: Why js not c++?
From: Benjamin Zeller, 2015-10-09