← Back to team overview

ubuntu-phone team mailing list archive

Re: Why js not c++?

 

Thanks, that would be great. :)

2015-10-09 13:31 GMT+02:00 Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>:

> Am 09.10.2015 um 13:28 schrieb Richard Somlói:
>
> Could we somewhere find this result? I'm very excited because of this. :)
>
> In case we get the OK from security (please keep in mind that still could
> stop the whole thing),
> we will write a big and nice blogpost about it :). With figures and
> barcharts ;)
>
>
> 2015-10-09 13:20 GMT+02:00 Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>
> :
>
>> 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 :).
>>
>> 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
>>
>
>
>
> --
> 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
>
>

References