Qt 5.9.5 Doubles Qt Quick Performance On 64-bit ARM, 18x JavaScript Improvement

[phoronix]

Phoronix: Qt 5.9.5 Doubles Qt Quick Performance On 64-bit ARM, 18x JavaScript Improvement

The Qt Company had been working on performance improvements for 64-bit ARM (AArch64) as part of the Qt 5.9 LTS cycle and continuing through with the ongoing long-term support point releases, and that work is paying off...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-5.9.5-AArch64-Jump

[Guest]

They didn't have a Javascript JIT on ARM so far? Jesus, how was Ubuntu Touch even remotely able to run fluidly?

[marty1885]

Wait what!? So for all these years I've written QML apps for Android and I don't even know it does not have JIT. Should I be amazed or terrified by the performance it is running on my phone. LOL

[Timo Jyrinki]

They didn't have a Javascript JIT on ARM so far? Jesus, how was Ubuntu Touch even remotely able to run fluidly?

Ubuntu Touch was running 32-bit arm, that had JIT way earlier. When the switch to arm64 + Ubuntu 16.04 (+ snap + ...) was in horizon, the arm64 JIT support was started to be backported from Qt 5.7.

[carewolf]

Wait what!? So for all these years I've written QML apps for Android and I don't even know it does not have JIT. Should I be amazed or terrified by the performance it is running on my phone. LOL

Well QML has been designed to integrate with C++, so any computational heavy stuff is done using C++, and any graphics is done with OpenGL, which leaves just a bit of glue.

The problem is if people integrate bigger JS frameworks and tries to use that in QML, then it needs more performance, but it is technically using QML wrong.

[brrrrttttt]

Well QML has been designed to integrate with C++, so any computational heavy stuff is done using C++, and any graphics is done with OpenGL, which leaves just a bit of glue.

The problem is if people integrate bigger JS frameworks and tries to use that in QML, then it needs more performance, but it is technically using QML wrong.

Nailed it. JS in QML is only supposed to be very light glue between C++ QObjects(+signals/slots) and QML GUI.

[caligula]

Nailed it. JS in QML is only supposed to be very light glue between C++ QObjects(+signals/slots) and QML GUI.

But isn't that how any GUI toolkit would work? The heavy processing is native, while high level code just glues together the MVC or some other components.

[carewolf]

But isn't that how any GUI toolkit would work? The heavy processing is native, while high level code just glues together the MVC or some other components.

When you come from a C++ toolkit like Qt, it already is in native mode. And when doing HTML5 you don't have much of a choice except use JS

[RealNC]

Wait what!? So for all these years I've written QML apps for Android and I don't even know it does not have JIT. Should I be amazed or terrified by the performance it is running on my phone. LOL

Unless you're crunching numbers or have some huge, complicated call stacks or algorithms in JavaScript, I'm not sure you'd notice anything :P

[caligula]

When you come from a C++ toolkit like Qt, it already is in native mode. And when doing HTML5 you don't have much of a choice except use JS

Ok that's true, but many modern toolkits use a non-native high level language as the glue layer. JVM langauges, .NET languages, Lua, Python, Perl, PHP, JS, Erlang, ...