Hello,

Some time ago I opened a bug report, that has been closed as "WONTFIX", about the lag on the first opening of plasma 5 elements like menu, calendar, network as you can see in the video :

https://bugs.kde.org/attachment.cgi?id=93229

Once you have opened these elements it's fast. Everything feel fast on Plasma 5 except that.

The reason of the lag is, and I quote David Edmundson, "The first time you open it has to load all the files and compile the JS. We do loading on demand to save memory."

The memory saved is about 50MB for a "normal" use with 1 desktop and few (10) plasmoids and I don't think it worth it, especially on the now fairly common systems with 3GB or more.

David also said that 5.4 will bring a huge boost but that was not the case.When I click on the clock to display the calendar on my Core i3 w/ SSD with Plasma 5.5.1 almost 2 seconds pass before the calendar is displayed.

David also said "We are constantly improving performance." and closed the bug report. I believe him when he says that they are constantly improving performance but every first click on the plasmoids is frustrating and there is almost no difference between Plasma 5.3 and Plasma 5.5.

I think that we should preload all the needed plasmoids to avoid the need to load all the files and compile the JS at the moment you first click on it. Or at least we should add an option to achieve this if the user choose the speed again that few MB saved. If the user have a powerful computer, want it to be reactive and there is no technical difficulties, he should be able do to it. Don't you think ?

These few MB saved come at the price of a really bad first impression and God know that KDE don't need that. If you have listen the last Linux Action Show 395 you can ear that they have the same feeling about Plasma 5. It can be felt sluggish on the first time elements opening :

https://youtu.be/E02gHmG61ro?t=55m00s
https://youtu.be/E02gHmG61ro?t=1h8m25s

Like I said that make bad press and bad feeling about the Plasma 5 desktop for nothing.

We should achieve the speed of Plasma 4 even on first opening of an element. It should be at least as fast on the new version of Plasma. I would even say that on this next gen Plasma 5 it should be faster than before.

So, please make Plasma 5 load everything on boot or at least give us the option to choose.

Don't misunderstand me, I love using Plasma and the KDE technologies, I'm really thankful and I have a lot of respect for the people behind this.

Thank you very much !

This is nothing KDE could improve. There are claims that the performance of QtQuick dependes on the actual QML (which is declarative ... ... seriously?) but the truth is that QtQuick is dead slow on loading/creating contexts.
It always has been and I've personally not witnessed any improvement in that regard. The "improvements" are that we try to avoid doing that by imo more than questionable things, see eg. https://git.reviewboard.kde.org/r/124136/

And it's not "50MB" it's "any amount of RAM, depending on your config" (more plasmoids, more memory) *and* this does no way mean things would magically fasten up. On the contrary.
plasmashell already takes ages to load anyway and you can just assume to double that time by sync loading.

luebking wrote:This is nothing KDE could improve.

Not really, after all that's "you" the KDE devs that make the code and choose the underlying tech

luebking wrote:And it's not "50MB" it's "any amount of RAM, depending on your config" (more plasmoids, more memory)

Right. I meant for a "normal" use with 1 desktop and few (10) plasmoids. I have added it to my first post.

luebking wrote:the truth is that QtQuick is dead slow on loading/creating contexts. It always has been and I've personally not witnessed any improvement in that regard. this does no way mean things would magically fasten up. On the contrary. plasmashell already takes ages to load anyway and you can just assume to double that time by sync loading.

That's right. So why not at least give the choice to the user. Since Plasma 5 can't load QML/QtQuick elements fast why not add an option to choose either a slower load at login (I prefer that) or a slow load everytime you want to use a plasmoid ?

> So why not at least give the choice to the user.
I don't excel in QML at all, but it looks quite as if that would require two implementations of everything *shrug*

luebking wrote:I don't excel in QML at all, but it looks quite as if that would require two implementations of everything *shrug*

I hope that's not the case... Anyway we really need a solution to this lag that kill the user experience.

Is the QtQuick Compiler used in Plasma ?

it reduces the application startup time and allows for a much faster execution

http://doc.qt.io/QtQuickCompiler/

I doubt so - and it seems to add limitations to QML:
https://mail.kde.org/pipermail/plasma-d ... 44342.html

I don't see what limitations it can add to QML. But I'm confident in the higher performance

In order to use the Qt Quick Compiler, your application needs to be prepared:

- Create a .qrc file for your application and include all the files your project needs, including .qml , .js and qmldir files.
- Add the file name of your .qrc file to RESOURCES in your .pro file.
- Change your application to use qrc: URLs instead of file: in order to become file system independent.
- This way all dependent files are bundled into your application binary and you should verify that your application works without the .qml source code in the file system.

> don't see what limitations it can add to QML
Dynamic extensions, see the response mail.

> But I'm confident in the higher performance
Confidence doesn't substitute numbers. Be prepared for runtime overhead to remain. Creating GL contexts *is* expensive and notably on some (nvidia) drivers.

Ok so, since you find a flaw to everything I suggest what do you think it can be done to improve Plasma 5 performance ?

I don't "find a flaw to everything" but merely pointed facts others already pointed out.
And my present finding is that you either live with it, get a faster system or abandon QtQuick, sorry. I've no hope left that it's ever gonna be "fast" in terms of "light" - it will be caught over the next decade by HW upgrades, that's all.

luebking wrote:And my present finding is that you either live with it, get a faster system or abandon QtQuick, sorry. I've no hope left that it's ever gonna be "fast" in terms of "light" - it will be caught over the next decade by HW upgrades, that's all.

That's pretty disappointing...
What a bad choice of technologie. I can see the benefit of QtQuick but if that come at so bad performance why even bother using it ?
That remind me the QML app that take 5s to start on an Ubuntu phone... https://youtu.be/L4NiPa-k7P8?t=45s

What a bad choice of technologie.

If you know any better one say it.

Honestly I don't see anything that is better.

Raster graphicsviews would take far less overhead on creation (ie. "on-the-fly usage") and declarative "programming" is frankly just a stupid approach.

It's promoted as "every fool can participate", but they can't - or at least QtQuick isn't robust against that at all, see eg. https://bugs.kde.org/340294 or https://bugs.kde.org/show_bug.cgi?id=348385 (also check the solutions: that's kinda micromanagement for size determination!)

On the bottom line, QtQuick severely limits your flexibility, but does no way protect you from shooting yourself. On the contrary.
The "brains-off autopilot" mode causes such bugs (which then are also no way simple to debug. The vast majority of "weird crashes somewhere in QtQuick" bugs in are still open and *no one* has figured what instruction the state machine "doesn't like" - people are at best poking around; the backtraces are meaningless)

And on top of all this, there's a complaint every. f******. day. about "plasma takes 100% cpu because of some animation"
https://bugs.kde.org/show_bug.cgi?id=336274
How hard can it be to simply constrain the repaints to something reasonable? Old school uncool QWidget has done that since Qt 1.x (yes, there might be different opinions on "reasonable" but then you default to eg 60FPS and offer some config mechanism)

Sorry to say, but from all of my experience, QtQuick is not a very good implementation of not a very good concept.

As I got PMd here...

I stick by what I said in the report and there is a difference between 5.3 and 5.5 . I have profile traces to prove it - and we are always improving things.

As for the rest, the main summary is:
Good QML is fast. Bad QML is not.
It is a langauge that isn't robust to having changes layered on and on and it is very easy to end up with utter rubbish.

- Would the QML compiler help anything?
Not really.
A few things:
1) it's propretiory, so we can't use it.
2) even if it wasn't, it links internals of Qt - so if your distro changed Qt version (even a minor patch release) and you don't rebuild plasma. Everything would just instantly-crash
3) it wouldn't help much
We can measure the impact it'd have - creating new objects in QML consists of 2 parts. Compiling the QML and instantiating the objects.
Run it in qmlprofiler and see for yourself. The compilation is scarcely an overhead.

- Would preloading help?
I don't think that's the right approach to fixing things. It's like fixing battery life span by attaching a nuclear generator to your laptop. Not a long term solution.

- Can things be fixed?
Yes. QML has some amazing profiling tools (qmlprofiler). We are not utilising that enough.
I did it once with the Widget Explorer - it was near instant when I finished. Then it got multiple rounds of changes and it's back to being slow again.
It's hard to optimise whilst applets are changing; you can't optimise something until you have a finished product.

I also strongly suspect we're hitting a completely stupid timer in appletquickitem - compactRepresentationCheckTimer adding 1/4 of a second onto the first launch. Feel free to look, you might accidentally be a hero that saves a lot of time.

- Is QtQuick bad?
To blame the underlying tech (which we know from demos can deliver extremely fast performance) is vastly vastly premature, particularly without a coherent opposing argument.

It does suffer in a few places from being a "new" tech, and us using it in way's it not really designed for (having lots of windows) but that's someting constantly improving.