Config/Skin Resource Usage Tips and Discussion

[Yincognito]

[...] but at the end of the 120 updates all three variants were between the upper edge of 0.28X% to lower edge 0.30X% average CPU, say 0.01% to 0.02% fluctuation, no pattern or lean of any particular one that I could see.
Just checked again, Yin and my first config shows 0.11X%, the my second config shows about 0.17%, so assuming the 0.11% is fairly accurate, this simplest skin is we'll say up to 0.1% off, perfectly fine for the normal user or even an attentive skin author.

In the long run, the AverageSize method (i.e. your second variant) and the one based on current measurements (i.e. what my variant and your first variant do) will probably be very close to one another, because the averages generaly flatten over time. In the short and medium term though, they won't always match. Try this and you'll see:

Code: Select all

[Variables]

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[MeasureCPU]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Name=Rainmeter

[MeasureGrossUpdates]
Measure=Calc
Formula=measureGrossUpdates + 1

[MeasureGrossCPU]
Measure=Calc
Formula=measureGrossCPU + measureCPU

[MeasureAverageCPU]
Measure=Calc
Formula=measureGrossCPU / measureGrossUpdates

[MeasureAverageSizeCPU]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Name=Rainmeter
AverageSize=[MeasureGrossUpdates]
DynamicVariables=1

---Meters---

[MeterComparison]
Meter=STRING
X=0
Y=0
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Update Number = [MeasureGrossUpdates]#CRLF#------------------#CRLF#Current Val = [MeasureCPU:2]#CRLF#------------------#CRLF#AverageCurr = [MeasureAverageCPU:2]#CRLF#AverageSize = [MeasureAverageSizeCPU:2]"
DynamicVariables=1

Preview:

AverageSize vs AverageCurrents.jpg

The difference between the AverageSize average and the average based on the current measurements will as big as the fluctuations in the CPU usage over a couple of milliseconds are.

Bottom line is, AverageSize is perfectly fine and accurate on its own, if it's the only measurement displayed. If, however, one also displays the current measurements, the AverageSize measurement will NOT match the average of the current measurements, simply because it is based on its own internal measurements, which are different from the current measurements, since we talk about two DIFFERENT measures (i.e. [MeasureCPU] and [MeasureAverageSizeCPU]) which measure things at a couple of milliseconds time interval difference from one another. In that very short time interval difference, the CPU usage may or may not be very different, hence the difference in measurements.

[Alex88]

If I have in my skin several meters and measures and I set them all to UpdateDivider=-1, in this case, would there be any performance difference between Update=20 and Update=1000?

I reduced it to just my controller config, and set UpdateDivider=-1 to all measures and meters. This is a quick run of Update=20 and Update=1000, UsageMonitor skin set to the normal Update=1000 for 120 seconds.

UpdateRate.png

So 0.0075% difference, though that's given my controller skin is currently pretty small, only 35 combined measures and meters. Just a rough approximation using line numbers of the All CPU Meter within Gadgets from SilverAzide could have 850ish measures or meters, so going proportionally, that would have any one fully-featured gadget to have a difference of about 0.18% average CPU usage difference for 20 vs. 1000. Of course, this extrapolation is at most a guess since the various meters and measures definitely use different levels resources and gets pretty far into hypotheticals.

...
I think it doesn't matter from the not-updated measure / meter perspective, but it does matter from a skin's perspective, since even though those measures / meters themselves won't update, the skin will and also get redrawn according to the update set in the [Rainmeter] section. At least that's what I believe it happens, according to the manual.

Makes sense, and gets further into the update logic: https://forum.rainmeter.net/viewtopic.php?p=118764#p118764

So even if every measure and meter is set to update once, the skin itself still goes through each overall update rate to check if something has changed, but the rough test above shows anything from tiny to fairly big, short of ginormous, isn't substantially affected from a reasonably faster Update rate if all is set at UpdateDivider=-1, even at 20 ms possibly, but I think somewhere around there is the limit for the 'optimum' situaiton of everything set to update only once.

I did try 10 ms with All CPU Meter (my configs are still too basic to quantify any GFX stuff) and the CPU bars were jumping all over the place, while at 20 ms it still could keep up, but at that fast update rate that probably gets into another realm.

Update=10 is at the very least checking all measures and meters 100 times/second even with UpdateDivider=-1 for all (would be 85,000 checks/second for AllCPUMeter), Update=20 is 50 times/second, etc., which wraps back around to following the general practices that have been mentioned, a fast update rate only on the stuff that really needs it.

Brian and jsmorley, how hopelessly lost into the weeds are we?

[Yincognito]

Brian and jsmorley, how hopelessly lost into the weeds are we?

Yeah, I think they're busy with other things at the moment...

[Active Colors]

Oh thank you, Yincognito and Alex88!!

[Yincognito]

Oh thank you, Yincognito and Alex88!!

What for?

[Alex88]

What for?

ec07_for_science.jpg

[Yincognito]

ec07_for_science.jpg

Yeah, just began trying to optimize my skin suite even more. I don't know if I'm going to complete this, as it's a bit laborious to slightly rewrite 15+ skins, but I'll try not to use dynamic variables at all (using the !SetOption trick instead) and hopefully improve the CPU usage during animations by not manually redrawing the meters and just let Rainmeter do that during its (or ActionTimer, if the tests will support that variant - which they didn't until now) updates. AudioLevel / Win7Audio skins will be the last in my optimization attempt, as they are a special case.

The things that's uncomfortable in this endeavour is the fact that one cannot know for sure if there's any gain by doing the optimization until that optimization is complete. It would be nice if there was a way to estimate that beforehand.

[Yincognito]

Some news and updates about the optimizations and resource usage tips, in my case:

- given up on rewriting my skins to avoid dynamic variables, as I measured the CPU usage of some similarly built (and of a similar amount) but basic skins and the dynamic variables impact is minimal on "normal" skins. On idle, the average for all the skins (that were using dynamic variables) was 0.93% CPU usage; a similar number of basic skins having no dynamic variables used 0.57% of the CPU. Considering the latter were just very basic skins, it became obvious that if they were exactly as the original ones but no dynamic variables the difference would have been even smaller, almost negligible.

- found out why the CPU usage of my skins increased when other CPU/GPU intensive software (like playing a clip in Chrome) were active and running in the foreground; it turns out it wasn't the Audio skin (or AudioLevel) needlessly consuming the CPU, but the fact that I let the meters in my fast updated animated skins to update at that (fast) rate. As soon as I updated those meters manually only when needed and otherwise set their UpdateDivider to -1, the CPU usage increase became significantly less. Sure, I wasn't using ActionTimer for the animation (for other reasons that don't bear much relevance here), but I can't stress this enough: on a fast updated skin, make sure you set either negative update rates or at most 1 second update rates to meters that don't need a fast update. Doing that in my 3 animated skins reduced my suite's CPU usage when Chrome was playing a video in foreground from 6% or more to between 1.5% and 2% (and of course, to the usual 0.5% when idle). Problem solved!