Bug 335442

Created attachment 86870 [details]
screenshot of sysprof

Make sure kded5 is running.

There's a known bug in which if kded5 isn't running it constantly rebuilds the .desktop file index.

If that's not the reason can you upload your original sysprof log?

(In reply to comment #2)
> Make sure kded5 is running.
It's running.
> 
> If that's not the reason can you upload your original sysprof log?
Nope, didn't save it.

But I made another one. ;-)

Created attachment 86884 [details]
Log Output of sysprof

Got info, reopening.

Ok, good news is, that I found the trigger for this.

I had—for testing purposes (-> Time zone bug)—an analogue clock in my panel and that resulted in a significant load increase.
When I remove the clock, the load drops instantly (approx. 4-5 minutes cpu time in 8 hours). I can observe the same by adding a clock to the desktop (which only works in folder mode). It doesn't matter if the clock shows the seconds or the time zone, the outcome is the same.
The digital clock seems to be ok.

Output when adding the clock:
Arrived mimeData () ("text/x-plasmoidservicename", "text/plain") at 1875 ,  14
adding "org.kde.plasma.analogclock"
DIALOG:  hiding dialog.
file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/views/Desktop.qml:90: TypeError: Cannot read property 'preventWindowHide' of null

And on removing it:
QObject::disconnect: No such slot QObject::dataUpdated(QString,Plasma::DataEngine::Data)
QObject::disconnect:  (receiver name: 'DataSource')
QObject::disconnect: No such slot QObject::modelChanged(QString,QAbstractItemModel*)
QObject::disconnect:  (sender name:   'Local')
QObject::disconnect:  (receiver name: 'DataSource')

hmm, 4-5 minutes in 8 hours is relevant but not huge..
may be in size with the rotation animation it's doing when the time changes?

iirc also scenegraph is documented to be less efficient, more opengl context switches when there is some item rotated at an angle not a multiple of 90 degrees
(that's the case of the clock hands)

(In reply to comment #7)
> hmm, 4-5 minutes in 8 hours is relevant but not huge..
Just to make sure you understand that correctly:
Without the analogue clock: 4-5 min cpu time/8h
With the analogue clock: ~ 2-3h cpu time/8h

*** Bug 337526 has been marked as a duplicate of this bug. ***

I put this through qmlprofiler. There is only one binding changing every second (as you'd expect). 

But the painting is a bit funny; it's practically /always/ painting.
The SpringAnimation inherits a duration 250ms; so it /shouldn't/ be that, but it's possible it ignores that and keeps animating until the object is completely at rest. I'll have a play.

See attached screenshot.

Created attachment 87800 [details]
QMLProfiler of analog clock

Green blocks at top show painting.
2 Purple lines near bottom are ticks from the clock.

Git commit 268910eb4abf974adfd1f9e9bc0fda7fc866c6d7 by David Edmundson.
Committed on 18/07/2014 at 16:02.
Pushed by davidedmundson into branch 'Plasma/5.0'.

Replace SpringAnimation with NumberAnimation with EaseOutIn

SpringAnimation ignores duration property and will keep animating until
the item has stopped springing; this takes a long time >= 1s just with
the movements getting smaller.

This means the analog clock is constantly repainting the entire desktop
causing high load.

This now restricts it to 200ms, so it's 5x less load.

REVIEW: 119357

M  +8    -2    applets/analog-clock/contents/ui/Hand.qml

http://commits.kde.org/plasma-workspace/268910eb4abf974adfd1f9e9bc0fda7fc866c6d7

Bernd can you confirm if this fixes it for you.

(In reply to David Edmundson from comment #13)
> Bernd can you confirm if this fixes it for you.

Unfortunately, no. I just updated to current head (953d6b), restarted plasmashell (should be enough, right?) and let it run with an analogue clock on the desktop for a couple of hours (approx. 8h).
In that time, it used up 2h of cpu time, in the end the load was at 50%. Removing the clock after that time instantly resulted in a big drop in the cpu load.

Sorry to disappoint you. :(

Forgot to reopen.

I'm not 100% sure, it might have improved to some degree, but the issue is still there. Having the analogue clock on your panel/desktop will result in a significant increase in cpu load, which gets worse over time.

I.e. with my cpu, the normal plasmashell load is somewhere below 2.5%. Adding the clock results in an increase to 10-20%, after a couple of hours, it's at 50%.

In addition to CPU time, it also increases the workload on GPU significantly.

Created attachment 87958 [details]
radeontop with clock

Created attachment 87959 [details]
radeontop without clock

is this still valid?

At least for me this is fixed but for extra performance one could try to port it to RotationAnimator from RotationAnimation

Marked as fixed then, if it persists, still, please reopen yet again.

I let it run for approx. 10h on Plasma 5.0.95.

Afaics, it didn't increase the cpu load significantly (which was different before), so it indeed seems to be fixed.

Git commit 7033e71812c8d04dc33c629e1e504d7b37a305ad by David Edmundson.
Committed on 11/12/2014 at 20:27.
Pushed by davidedmundson into branch 'master'.

cache QTimeZone for the lifespan of the TimeSource don't recreate every minute

QTimeZone::systemTimeZoneId() will open /etc/localtime every single time it is called.

We are calling this in ::updateTime which happens every single minute, potentially
every second.

REVIEW: 121453

M  +12   -14   dataengines/time/timesource.cpp
M  +2    -0    dataengines/time/timesource.h

http://commits.kde.org/plasma-workspace/7033e71812c8d04dc33c629e1e504d7b37a305ad