ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #16133
Re: Why js not c++?
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.
>
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
>>>
>>
>
Follow ups
References