Alternative to QML and V4 engine
Closed, WontfixPublic

Description

Description

We need an alternative to QML, something that's honest-to-god compiled and not interpreted. And fast.
We need our desktops and phones to be responsive and our software to work on any old thing we manage to find.

QML may not be fit for our purposes. As we are mostly using x86_64 desktops it's very easy to get used to responsiveness.
But if we want our software to really work in ARM world we may need to reconsider our choice.

  • QML code is easy to write but it takes several rounds of profiling and review to free the code of resource hogs
  • QML is quick due to caching and JIT but this brings complications and debugging difficulties when you encounter a bug
  • QML is JIT-based, which means slowness in first use of plasmoids and apps and increased memory usage after code is compiled
  • QML requires whole Javascript V4 interpreter up and running in order to operate

What it will take

<What do we need to do to make this reality? What kind of support do you need?>

How we know we succeeded

<Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?

Relevant links

<any links that will help people find more information and understand the goal better>

I am willing to put work into this

  • add your name

I am interested

  • add your name
Kanedias created this task.Jun 11 2019, 2:08 PM
Kanedias updated the task description. (Show Details)

We need an alternative to QML

This seems inconsistent with the direction of the QT, Plasma, and KDE apps. I can appreciate a good macro task, but this may be... a bit too macro. :)

This was posted in response to http://blog.lydiapintscher.de/2019/06/09/evolving-kde-lets-set-some-new-goals-for-kde/

Which doesn't mention anything about micro-tasks, just things that uses would want.

apol added a subscriber: apol.Jun 11 2019, 2:35 PM

Having a performance goal can make sense. Stepping ahead and saying all performance problems are QML is odd and not something I'd say we can get behind as is.

In T11077#188076, @apol wrote:

Having a performance goal can make sense. Stepping ahead and saying all performance problems are QML is odd and not something I'd say we can get behind as is.

+1

Not all performance problems are from QML. Besides, that'd undermine all the effort KDE team has put into polishing the system.
Alternative is not a replacement. I merely think for arm/phones we need something else, rather than waiting for CPUs to evolve.

Not all performance problems are from QML. Besides, that'd undermine all the effort KDE team has put into polishing the system.
Alternative is not a replacement. I merely think for arm/phones we need something else, rather than waiting for CPUs to evolve.

Do you have any evidence that QML is a performance bottleneck on phones? Android apps are written in QML and they seems fine to me.

I don't. At this point any proof that I can provide just looks like nitpicking. I remember seeing it clearly in my old QML apps for Android but it was over a year ago. I tried screencasting it but on my desktop it's almost non-palpatable. I mean, my eyes can surely see it when I click calendar for the first time or when I scroll system notifications and track plasmashell memory usage in htop in other window, but it's hard to notice even in screencast. Apparently, the amount of optimizations that went into QML is enormous.

Ok, let's turn this into performance goal. Something along the lines of "should be fluent and run at 60 fps on Librem/PinePhone".

lydia updated the task description. (Show Details)Jun 15 2019, 7:14 AM
ervin added a subscriber: ervin.Jun 23 2019, 12:43 PM

I agree with the other comments, and would go even one step further: anything which is aiming at improving performance and at the same time pointing finger to a particular component or framework should come with measurements. That's how profiling anything starts.

mart added a subscriber: mart.Jun 25 2019, 10:47 AM

Moreover, in Qt6 Javascript and V4 will be optional in QML, which makes this even more moot

ngraham closed this task as Wontfix.Jun 25 2019, 11:00 AM
ngraham claimed this task.

I'm not sure this goal has a future as currently written. If you want to submit a more general "focus on performance" goal, I think that would be more fruitful. Thanks!

ngraham removed ngraham as the assignee of this task.Jun 25 2019, 11:01 AM