[Public] Why mobile web apps are slow & Food For Thought

[Marvin]

Jetzt auch mal zwei oder drei Worte zu dem Thema von mir:
1. Ein Benchmark mit SunSpider macht einfach keinen Sinn, denn SunSpider testet die CPU. Für 99% der Apps ist die CPU-Zeit total irrelevant, interessant sind I/O und Rendering/GPU (das kennen wir auch vom Desktop: synchrone Ausgaben auf stdout verlangsamen Programme enorm).
2. Damit andere Browser asm.js komplett implementieren können, muss Mozilla damit erstmal annähernd fertig sein.
3. Chromium enthält bereits Optimierungen, die asm.js beschleunigen, ohne dabei Kompatibilität zu ECMAscript zu verlieren
4. Damit dieser Benchmark relevant ist, muss der c code mit allen Optimierungen kompiliert werden, wird Firefox schließlich auch (das könnte zumindest erklären warum asm.js teilweise schneller sein soll als nativ). Zur besseren Vergleichbarkeit sollte auch der dalvik code aus dem c code generiert werden, c structs mit dalvik classes zu vergleichen ist nicht wirklich viel...
5. Tut mir leid, aber ich traue Benchmarks aus dem Hause mozilla, wo mozilla deutlich besser wegkommt nicht mehr. Die Vergangenheit hat mich gelehrt.

Sven Schmidt <snot.herry at gmail.com> wrote:
>Die frage ist halt, ob die Technologie akzeptiert wird. Wenn Google
>sich dagegen entscheidet, das ding zu unterstützen wird es wohl auch
>auf den Android Stock Browser und Chrome langsam laufen. Google hat ja
>seine eigenen Web sprachen am start und warum sollten sie die
>Konkurrenz unterstützen. Mich würde interessieren, wie Objective-C
>Code, der ja auch auf manuelles Memory Management setzt dagegen
>abschneidet. Da er ja mit SunSpider getestet hat: Ist Javascript nicht
>optimiert, schnell über Sunspider zu kommen? Hast du noch Tests mit
>anderen Programmen?
>
>Gruß 
>
>Sven
>
>
>On 29.08.2013, at 15:42, Constantin Berhard
><constantin at exxxtremesys.lu> wrote:
>
>> On 08/28/2013 10:46 PM, Thomas Darimont wrote:
>>> Eine reine HTML5/CSS3/JS basierte (mobile Web-) App kann aufgrund
>der
>>> (derzeit noch) zu geringen Leistungsfähigkeit von Smartphones 
>>> und mobilen Browsern / JS-Engines nicht an die Leistungsfähigkeit
>>> einer nativen App herankommen.
>>> 
>>> Mehr dazu findet man in dem sehr lesenswerten Artikel:  "Why mobile
>>> web apps are slow"
>>> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>> Hi,
>> 
>> ASM.js wird nur kurz angesprochen, verdient aber mehr Aufmerksamkeit.
>> ASM.js kann manuelles memory management. ASM.js Code kann man
>erzeugen,
>> indem man C++ Code (oder sonstigen Code, für den LLVM ein Frontend
>hat)
>> schreibt und ihn mit Emscripten übersetzt. ASM.js ist auch kompatibel
>zu
>> System, die die Optimierung nicht unterstützen. ASM.js liefert
>> Performance, die sogar die von "nativem" Dalvik-Code auf Android
>> übertreffen kann.
>>
>https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/
>> 
>> Meine Quintessenz aus dem ganzen wäre die folgende Strategie:
>Schreibe
>> Anwendungen in direkt ASM.js oder benutze Emscripten, um C++ nach
>asm.js
>> zu kompilieren. Das Qt-Framework ist bereits nach ASM.js portiert. So
>> müssten native Sailfish OS-Anwendungen sich direkt nach ASM.js
>> kompilieren lassen. => fast alle (alle außer Apple; also Android,
>> Firefox OS, Sailfish OS) Platformen abgedeckt mit nativer
>> APP-Performance oder besser (ASM.js >= Dalvik).
>> 
>> Bei Apple sieht die Lage ziemlich dumm aus: Apple verbietet in seinem
>> Store Anwendungen, die Alternativen zur Safari-Engine bereitstellen
>(wie
>> Firefox) und die Safari-Engine ist nicht auf ASM.js optimiert. Daher
>> würde dort wahrscheinlich die Performance leiden. Andererseits ist
>wer
>> sich durch den Kauf eines Appleprodukts so in seiner Softwareauswahl
>> einschränken lässt selbst schuld.
>>
>http://venturebeat.com/2013/04/15/mozilla-ceo-we-refuse-to-bring-firefox-to-ios-until-apple-lets-us-use-our-web-engine/
>> 
>> Trotzdem sind die Apps dann auf Apple und Blackberry immerhin
>überhaupt
>> lauffähig, wenn auch langsam. Das ist imho eine verdammt starke
>Leistung
>> für code once, run anywhere.
>> 
>> Viele Grüße,
>> Constantin
>> _______________________________________________
>> Public mailing list
>> Public at lists.hacksaar.de
>> http://lists.hacksaar.de/cgi-bin/mailman/listinfo/public
>
>_______________________________________________
>Public mailing list
>Public at lists.hacksaar.de
>http://lists.hacksaar.de/cgi-bin/mailman/listinfo/public