2015-10-09 13:20 GMT+02:00 Benjamin Zeller
<benjamin.zeller@xxxxxxxxxxxxx <mailto: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
<mailto: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
<mailto: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>
<mailto: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>
<mailto: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
<https://launchpad.net/%7Eubuntu-phone>
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
<mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
More help : https://help.launchpad.net/ListHelp
