david_edmundson wrote: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.

From quick testing it looks like this is really the issue, calling the slot directly (https://paste.kde.org/pk1yyptbz) fixes it and doesn't seem to break anything else.
Why is that timer there anyway? I couldn't find anything in git log...

I'll see how it works over the next couple of days.

David, did you profile how much time goes into the actual ARGB window creation and initial painting? It always seemed to me to be one of the biggest problems that we also had on P4 (and the main reason why I haven't considered Razor-Qt people insane for using QWidgets).

I guess it heavily depends on the graphics driver, but we might benefit from collecting these numbers.

ARGB should not be a problem per se - QMenu, QToolTip and DnD windows use it or are made to use it by the styles in Qt4 and Qt5.
It *was* a problem in the early KDE4 times due to driver behavior, but afaics that's long gone.

Creating GL contexts is notoriously slow on the nvidia blob, it should be "better" with the MESA drivers (but it's still expensive) - but thanks to ::setPersistentOpenGLContext() defaulting to true that (the GL context) should not be the troublemaker for plasmashell (at least lxr doesn't say it's disabled)

Callgrinding the start of the calculator example in qmlviewer, clearly QMetaObject::metaCall and QMetaObject::activate stick out with the payload being in QDeclarativeBinding::qt_metacall and two or three private symbols in libQt5Declarative - the window/context is probably expensive, but falls far behind actual QML handling.

This

Code: Select all

diff --git a/effects/presentwindows/main.qml b/effects/presentwindows/main.qml
index 0a34197..89c3ec0 100644
--- a/effects/presentwindows/main.qml
+++ b/effects/presentwindows/main.qml
@@ -18,16 +18,13 @@ You should have received a copy of the GNU General Public License
 along with this program.  If not, see <http://www.gnu.org/licenses/>.
 *********************************************************************/
 import QtQuick 2.0
-import org.kde.plasma.components 2.0 as Plasma
+// import org.kde.plasma.components 2.0 as Plasma
 
-Item {
-    width: units.iconSizes.medium
-    height: width
-
-    Plasma.Button {
-        id: closeButton
-        objectName: "closeButton"
-        iconSource: "window-close"
-        anchors.fill: parent
-    }
+Rectangle {
+    width: 24
+    height: 24
+    color: "black"
+    id: closeButton
+    objectName: "closeButton"
+    anchors.fill: parent
 }


Accelerates loading by factor >=30
If I import org.kde.plasma.components (but leave the rect), it's (still) faster by factor >=8

Using text: or iconSource: makes zero difference (once the icon is in the icon cache, I presume)


All time is spent in QQuickWindow::setSource(), showing/mapping the window has virtually no costs (but we can't use it since the result shows artifacts on all drivers, I assume some FBO/VBO isn't cleared when becoming invalid)

@luebking

Thanks for testing this!

drosca wrote:Why is that timer there anyway? I couldn't find anything in git log...

iirc it was due to some slot calling order, so was a quick and dirty fixthat stayed there...
if you can patch it it would be appreciated

notmart wrote:if you can patch it it would be appreciated

Sure, I will send patch tomorrow (if I don't find any issues, so far it looks fine).

paviluf wrote: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.

100-150MB is a more realistic number, plus a considerable difference in boot time (and a not justifiable waste spending boot time and memory for things that may well end up never used for the whole sessions).
Anyways loading immediately the full representation is an hack that should be not much more than an one liner, so it may be tested and some number gathered
It may give an idea where to move (otherwise I consider it just meaningless speculations).
I guess we'll end up preloading things (and eventually even unloading) based on statistical data gathered during session usage.

david_edmundson wrote:- 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.

To add on it, for sure QtQuick has issues, a technology like that needs *a lot* of years to perfect and is just on its infancy, but I still think is the best option moving forward in the future.
To do all the work and all the features we did in two years, with pure C++ and QWidgets would have taken at least 5-6 years (and not everything actually possible probably),
Scene based, declarative systems seems pretty much the direction a lot of the world is going right now, because while it does have costs, that's undeniable, what you can offer to the user UI-wise is just a lot more.

For a comparism, creating a QToolButton (inc. ensurePolished() and adjustSize()) is 3,000 times faster to achieve the same result.

david_edmundson wrote:As I got PMd here...

That was me and I thank you very much for commenting here.

david_edmundson wrote: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.

I believe you but the feeling hasn't changed and Plasma still take way too much time to respond.

david_edmundson wrote: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.

I don't want to be ungrateful but if we follow what you say Plasma is bad QML because it's slow ?

david_edmundson wrote:- 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.

Ok thanks for the clarification.

david_edmundson wrote:- 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.

A little option to load everything at boot can be a good compromise in the meantime. Maybe even make it the default for now. I don't mind using more RAM and have a boot that is 20s longer if Plasma 5 is snappy.

david_edmundson wrote:- 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.

I think that now Plasma is more mature a little bit of optimisations will be good

david_edmundson wrote:- 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.

You are very optimistic about QtQuick and I hope the (not so distant) future will prove you are right.

leszek1337 wrote:

What a bad choice of technologie.

If you know any better one say it.
Honestly I don't see anything that is better.

I tend to agree with what luebking said. Qt QWidget is a lot more faster. But I agree with what notmart said too.

notmart wrote:100-150MB is a more realistic number, plus a considerable difference in boot time (and a not justifiable waste spending boot time and memory for things that may well end up never used for the whole sessions).

On my system it really was something like 50MB. Even if it's 200MB I prefer this to a sluggish desktop

notmart wrote:Anyways loading immediately the full representation is an hack that should be not much more than an one liner, so it may be tested and some number gathered
It may give an idea where to move (otherwise I consider it just meaningless speculations).
I guess we'll end up preloading things (and eventually even unloading) based on statistical data gathered during session usage.

If it's as easy as you say it should be done as soon as possible. As an option maybe. The user experience will improve a lot and like I said, I (and a lot of people I think) don't mind using more RAM and have a boot that is 20s longer if Plasma 5 is snappy

luebking wrote:For a comparism, creating a QToolButton (inc. ensurePolished() and adjustSize()) is 3,000 times faster to achieve the same result.

You mean QtWidget vs QtQuick ? If that's the case I understand why Plasma 5 feel like that.

I'm afraid that we won't see any speed improvement in Plasma 5 for a long time...
David Edmunson barely (and, I can understand that, is probably bothered to) answer and it feels like he don't really care to make a workaround for the time being like an option to load everything at login. If I'm wrong David, just say it.

I just tested, for fun, the Nouveau drivers and Plasma 5 is much faster !
It's not as fast as Plasma 4 but it's maybe 2 or 3 times faster than with the Nvidia driver.
The lag on first click is not gone but it's very little now (except with the calendar plasmoid).