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