ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Fri, Oct 9, 2015 at 11:49 AM, Pete Woods <pete.woods@xxxxxxxxxxxxx> wrote:
>
>
> On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>
> wrote:
>>
>> On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning
>> <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.
>

Well, and Dalvik has seen heavy optimization work for years. It is
almost always possible
to optimize a runtime, it just takes time and resources. For that, if
developers want to do something now,
they can just switch to C++ for the heavy lifting.

@Zygote: Comes with its own set of issues, specifically regarding
security. We investigated into
the approach, but postponed implementation as we would have to do
something along the lines of [1].
So it's not as easy as just copying Zygote :)

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

In the limit case: certainly. However, calling out to more native*
languages to carry out
CPU-intensive tasks is common practice (in the Android world, too).

Cheers,

  Thomas

* where native usually is C/C++.

[1] http://wenke.gtisc.gatech.edu/papers/morula.pdf
> -Pete