It is currently April 23rd, 2024, 10:53 pm

Config/Skin Resource Usage Tips and Discussion

Get help with creating, editing & fixing problems with skins
User avatar
Alex88
Posts: 92
Joined: July 18th, 2020, 1:23 am
Location: California

Config/Skin Resource Usage Tips and Discussion

Post by Alex88 »

I found some mentions but didn't see a specific topic to this yet, and seems good to start it as a general discussion. Feel free to introduce other relevant questions here.

What tips are there to reduce skin resource usage, ex. CPU, GPU, memory usage?
A few main ones I've seen:
  • Basics: don't use tons of measures or meters in a config/skin, use images with unneeded high resolution, refreshing, fetching/parsing data, images, or talking with other skins unnecessarily often... what others are there?
  • Update Guide Update Logic: The overall skin update rate in the Rainmeter section shouldn't be set too fast; for most of the small skins I've tried, either the default 1000 ms is fine or anything below maybe 250 ms is generally not needed unless it's for a specific need.
    For one of my skins, I have Update set to 50 ms, but have all but three measures set to update once with UpdateDivider=-1, with those three measures only to show/hide small skins with their Updates the standard 1000 ms or slower.
    Are there any other downsides to a fast Update rate? It preforms well so far, Rainmeter has 22 MB RAM max and 2% CPU max for a settings skin and a barebones 'suite', but am just curious. My case for example:

    Code: Select all

    [Rainmeter]
     Update=50
     
    [Measure1] to [Measure3]
     One MouseXY Plugin and two measures watching its value
     No UpdateDivider
     
    [All Other Measures/Meters]
     UpdateDivider=-1
  • Variables Dynamic Cheat Sheet: For usage of Dynamic Variables, I think this thread goes into enough further detail, no questions from me currently, but just to provide links.
  • If possible, run the config on other/slower systems and see how it does there.
  • I know there are other points but can't think of any big ones at the moment, will add later.
Last edited by Alex88 on August 6th, 2020, 2:23 am, edited 2 times in total.
mak_kawa
Posts: 908
Joined: December 30th, 2015, 9:47 am

Re: Config/Skin Resource Usage Tips and Discussion

Post by mak_kawa »

Hi Alex88

I am not sure what is the practical meaning of this thread... but one thing I can respond is;
Are there any other downsides to a fast Update rate?
The downside of fast update I noticed is... rise of CPU utilization when the skin concerned is selected in the Manage Rainmeter -> Open log -> Skins dialog for monitoring, no matter what UpdateDivider= and DefaultUpdateDivider= option values... I couldn't believe when I first see this, but it's true.

Probably, the Skin dialog monitors the skin with the polling rate specified by Update= option of the skin. Am I wrong and/or misunderstanding something as always...? :-)
User avatar
Yincognito
Rainmeter Sage
Posts: 7151
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Config/Skin Resource Usage Tips and Discussion

Post by Yincognito »

Alex88 wrote: August 5th, 2020, 2:29 amWhat tips are there to reduce skin resource usage, ex. CPU, GPU, memory usage?
Yeah, in general, it all boils down to things like quantity and quality.

Quantity might refer to how many measures / meters / redraws / skins are active or happening in a certain amount of time, to how big those images / meters / skins are, or to how many (and what type of) other CPU / GPU intensive programs (other than Rainmeter) are running along those skins.

Quality might refer to how much those elements are optimized to take less CPU / GPU, either through efficient coding (e.g. using dynamic variables enabled measures or meters only when needed, or using no more than one AudioLevel plugin parent measure per machine, as although visualizers look nice and all, those measures are avid CPU usage eaters, and the needed fast updates for that kind of measures don't help either), negative update dividers or disabling elements one doesn't use at a certain moment in time.

Personally, I do have some experience on the matter, as I always look to force my 15+ skin suite to take less than 1% (I like 0.00% and 0.39%, but I become annoyed at 0.78%, to understand just how sensitive I am to those matters, haha!) on my "old" / "outdated" 2.3 GHz CPU and similarly old / outdated GPU card. The fact that the suite is minimalist does help with that in a way, and if it wasn't for my Audio skin (see the AudioLevel warning above), that would be accomplished ... on idle.

When my laptop is on idle (i.e. only the desktop with the skin suite, no mouse movement, etc.) my suite takes 1.80% CPU on average over 04:30 minutes (one of my skins is measuring that), and if I unload only the Audio skin the suite takes just 0.39% CPU on average over the same time interval. As soon as there are other programs maximized / actively running (like Chrome, for example, or a YT video playing in one of Chrome's tabs) the CPU usage dramatically increases, at 4.40% on average over the same time frame and 2.70% on average over the same time frame without the Audio skin (these percentages might vary from measurement to measurement, as there are obviously other factors involved). Bear in mind that although my suite is minimalist, it does have 9 of the skins set to Stay Topmost, 3 endlessly animated skins updated every 25 ms and the similarly animated Audio skin updated every 50 ms, not to mention pretty much all of the measures and meters having dynamic variables enabled, so it's not like I'm doing nothing in those skins...
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Alex88
Posts: 92
Joined: July 18th, 2020, 1:23 am
Location: California

Re: Config/Skin Resource Usage Tips and Discussion

Post by Alex88 »

mak_kawa wrote: August 5th, 2020, 12:08 pm I am not sure what is the practical meaning of this thread... but one thing I can respond is;
...
I don't have a particular answer for the thread in mind since my question was pretty open-ended, maybe I should have put it in the Tips and Tricks section, but remembered seeing across the various forums questions to the effect of "I made/am using a skin, it lags, what can I do?" and wanted to start an open topic for it here on the main forum.
mak_kawa wrote: August 5th, 2020, 12:08 pm The downside of fast update I noticed is... rise of CPU utilization when the skin concerned is selected in the Manage Rainmeter -> Open log -> Skins dialog for monitoring
...
Could well be, my guess it that once the About Rainmeter window is open, the Skins section has to start displaying all the measures and variable values for all active configs at their specified update rate as if they are their own meters, and would start using resources for that.
Yincognito wrote: August 5th, 2020, 12:26 pm Yeah, in general, it all boils down to things like quantity and quality.
...
That's a good way to categorize and explain it, yep.
Yincognito wrote: August 5th, 2020, 12:26 pm ... my suite takes 1.80% CPU on average over 04:30 minutes (one of my skins is measuring that) ...
That's smart to do: so far I just looked into Task Manager and roughly rounded my usage values up to the highest MB/percent, but will try that as I start adding more to the bare structure of the skins I have so far.
Yincognito wrote: August 5th, 2020, 12:26 pm ... to take less than 1% (I like 0.00% and 0.39%, but I become annoyed at 0.78%, to understand just how sensitive I am to those matters, haha!) on my "old" / "outdated" 2.3 GHz CPU and similarly old / outdated GPU card.
I know it seems to some as partially joking/superfluous when we're talking about very low percent usage with decent to high end modern CPUs and overkill of 16 or 32 GB of RAM, but to use it to tell the point that authors that release skins should be mindful of the computer specs of others; I think ideally a skin should run well and be unobtrusive resource-wise on even the slowest potatoes.

For fun I used to build many a computer from obsoleted school and business computer parts sent my way for repair or even just parts collection when I had access to such back in the MS-DOS/Win 3.1 days, so I understand working with potatoes. :D
User avatar
Yincognito
Rainmeter Sage
Posts: 7151
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Config/Skin Resource Usage Tips and Discussion

Post by Yincognito »

Alex88 wrote: August 5th, 2020, 10:56 pmThat's smart to do: so far I just looked into Task Manager and roughly rounded my usage values up to the highest MB/percent, but will try that as I start adding more to the bare structure of the skins I have so far.
Yep, the skin I wrote to measure that is very useful indeed. It makes my other skins better.
Alex88 wrote: August 5th, 2020, 10:56 pmI know it seems to some as partially joking/superfluous when we're talking about very low percent usage with decent to high end modern CPUs and overkill of 16 or 32 GB of RAM, but to use it to tell the point that authors that release skins should be mindful of the computer specs of others; I think ideally a skin should run well and be unobtrusive resource-wise on even the slowest potatoes.

For fun I used to build many a computer from obsoleted school and business computer parts sent my way for repair or even just parts collection when I had access to such back in the MS-DOS/Win 3.1 days, so I understand working with potatoes. :D
I completely agree. And yes, I started with potatoes as well in those MS-DOS/Win 3.1 days. :D The mentality nowadays is terribly superficial though: instead of making the resource consumption more efficient the answer is scrap it, buy a faster computer. If a skin is a CPU hog, the author tells you it's not his fault, it's because you have a "slow computer", LOL...
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
brax64
Posts: 172
Joined: July 8th, 2018, 8:05 pm

Re: Config/Skin Resource Usage Tips and Discussion

Post by brax64 »

Yincognito wrote: August 5th, 2020, 11:17 pm Yep, the skin I wrote to measure that is very useful indeed. It makes my other skins better.
Hi Yincognito,
just curious, your skin is something like that

Code: Select all

[MeasureRainmeterCPU]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Name=Rainmeter
AverageSize=5
Or something more sofisticated?
User avatar
Yincognito
Rainmeter Sage
Posts: 7151
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Config/Skin Resource Usage Tips and Discussion

Post by Yincognito »

brax64 wrote: August 6th, 2020, 12:02 am Hi Yincognito,
just curious, your skin is something like that

Code: Select all

[MeasureRainmeterCPU]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Name=Rainmeter
AverageSize=5
Or something more sofisticated?
Nah, it's more than that, but not that sophisticated - it's just math, after all. :D I never considered doing it using AverageSize, not sure why: either because I felt more comfortable controlling things in the code, either because it needed a dynamic adjustment and such. In any case, I just tried the AverageSize method (thanks for mentioning it) along with a couple of new measures like below designed to replicate what AverageSize does, and the results were a bit different, not sure why - and in the end I trust my method more. :sly:

The bits below are obviously tailored to my suite, but they make some logical sense, so they shouldn't be hard to understand:

Code: Select all

[Variables]
UpdateInterval=1000
SecondsInUpdateInterval=(#UpdateInterval#/1000)
NetElapsedUpdates=0

...

[Rainmeter]
Update=#UpdateInterval#
DynamicWindowSize=1
AccurateText=1

...

---Measures UsageMonitor---

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

---Measures Rainmeter---

[MS_Rainmeter_RainmeterGrossElapsedUpdates]
Measure=Calc
Formula=(((MS_Rainmeter_RainmeterGrossElapsedUpdates*#SecondsInUpdateInterval#>3600)?(0):(MS_Rainmeter_RainmeterGrossElapsedUpdates))+1)
OnUpdateAction=[!SetVariable NetElapsedUpdates ([MS_Rainmeter_RainmeterGrossElapsedUpdates]-1)]
DynamicVariables=1

[MS_Rainmeter_RainmeterElapsedMinutes]
Measure=Calc
Formula=(Trunc(Round(#NetElapsedUpdates#*#SecondsInUpdateInterval#)/60))
RegExpSubstitute=1
Substitute="^(.*)$":"0\1","^.*(.{2})$":"\1"
DynamicVariables=1

[MS_Rainmeter_RainmeterElapsedSeconds]
Measure=Calc
Formula=(Trunc(Round(#NetElapsedUpdates#*#SecondsInUpdateInterval#)%60))
RegExpSubstitute=1
Substitute="^(.*)$":"0\1","^.*(.{2})$":"\1"
DynamicVariables=1

[MS_Rainmeter_RainmeterElapsedTime]
Measure=String
String="[MS_Rainmeter_RainmeterElapsedMinutes]:[MS_Rainmeter_RainmeterElapsedSeconds]"
DynamicVariables=1

[MS_Rainmeter_RainmeterCurrentCPUUsage]
Measure=Calc
Formula=(Round(MS_UsageMonitor_RainmeterCurrentCPUUsage,2))
RegExpSubstitute=1
Substitute="^([^\.]*)$":"\1.","^(.*)$":"  \100","^.*(.{3}\..{2}).*$":"\1"
DynamicVariables=1

[MS_Rainmeter_RainmeterAggregateCPUUsage]
Measure=Calc
Formula=((#NetElapsedUpdates#=0)?(0):(MS_Rainmeter_RainmeterAggregateCPUUsage+MS_UsageMonitor_RainmeterCurrentCPUUsage))
DynamicVariables=1

[MS_Rainmeter_RainmeterAverageCPUUsage]
Measure=Calc
Formula=(Round(MS_Rainmeter_RainmeterAggregateCPUUsage/((#NetElapsedUpdates#=0)?(1):(#NetElapsedUpdates#)),2))
RegExpSubstitute=1
Substitute="^([^\.]*)$":"\1.","^(.*)$":"  \100","^.*(.{3}\..{2}).*$":"\1"
DynamicVariables=1

...

---Meters---

[MT_Rainmeter_RainmeterCurrentCPULoad]
Meter=STRING
...
Text="[MS_Rainmeter_RainmeterCurrentCPUUsage] %"
DynamicVariables=1

[MT_Rainmeter_RainmeterElapsedTime]
Meter=STRING
...
MeasureName=MS_Rainmeter_RainmeterElapsedTime
Text="%1"
DynamicVariables=1

[MT_Rainmeter_RainmeterAverageCPULoad]
Meter=STRING
...
Text="[MS_Rainmeter_RainmeterAverageCPUUsage] %"
DynamicVariables=1
Since my update interval is configurable, I calculate first how many seconds are in it, so the time is based on that. I compute and display things like averages based on the update interval, but I display time based on seconds, so that was necessary. The "update counter" (i.e. the 1st Calc measure) resets itself after 1 hour, but that's only because I didn't have more space to display things in my little skins and it's configurable anyway. The "gross" is basically the "net" plus 1, so that the "net" starts at 0. As for the rest, it's just about adding Rainmeter's current CPU usage to its aggregate, then dividing this by the "net" number of updates, taking care a bit about the divide by 0 scenario.

P.S. Yes, I could have used an Uptime measure for the time, but I didn't like something about that approach (can't remember what now), so I went simplistic about it.

EDIT: Regarding the AverageSize method, this doesn't suit well if one wants to display the current usage at the same time (like I do). The reason is that the current and the AverageSize measures being different from one another, they measure the usage at slightly different moments in time, so the average sized result isn't going to match the average calculated based on the current measurement, and if it does, it will only happen very rarely. Obviously the AverageSize method is way simpler, but it just doesn't look right to have, say, two subsequent "current" measurements of 1% and 2% and the average sized result to be anything other than 1.5%, just because there were a couple of milliseconds between the current and average sized measurements. So in the end, like I said, I trust my rudimentary method more since it is calculated based on the "current" measurements that just happened, instead of some internal values in the array used by AverageSize that cannot be accessed (maybe that could make a good thread for a Feature Request here on the forum).
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
User avatar
Alex88
Posts: 92
Joined: July 18th, 2020, 1:23 am
Location: California

Re: Config/Skin Resource Usage Tips and Discussion

Post by Alex88 »

So I tried a quick test of that and and a simplified version for us that aren't wizards with regex yet :D (I get the main idea of the regex though) and this is the config I used:

Code: Select all

[Rainmeter]
 Update=1000

[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

[Meter]
 Meter=String
This is the result of the above after leaving it for 1 hour of idle time with that and Yin's CPU measuring skins and my barebones 'suite' active:
AverageRainmeterCPU.png
measureAverageCPU was even lower initially, saw it at 0.005X before it caught up to my mouse actions. And that number represents a percent already, not the decimal of average CPU usage, so that's an average of about 0.005% CPU usage on idle, pretty cool (I didn't add in the appropriate range with Min= and Max=, only the standard UsageMonnitor shows the correct range). Yin, your config returned 0.00 initially and then rose to 0.01, which makes sense since you have it rounded and truncated.

After that I restarted Rainmeter, and tried spamming buttons on my controller/settings skin for about 2 minutes straight (could simulate 15 clicks/actions or so per second), and got 6.75% average CPU for my config and 6.68% for Yin's, but just switching to Yin's config in the About panel a second or two after reading the first number is probably enough to make it drop those hundredths, so I could make a skin comparing those in real time but I'm sure it would give numbers that basically match.

Then restarted Rainmeter once more, and just used the computer normally, pretty much up through writing this, and got 0.20973% average CPU for my config, and 0.21% for Yin's, again makes sense because of rounding/truncating.

And then just thought of an even easier one, using a high AverageSize on UsageMonnitor itself, tried 120 (two minutes with Update=1000) of average computer usage:

Code: Select all

[Rainmeter]
 Update=1000

[MeasureRainmeterCPU]
 Measure=Plugin
 Plugin=UsageMonitor
 Alias=CPU
 Name=Rainmeter
 AverageSize=120

[Meter]
 Meter=String
Before two minutes have elapsed, it has to slowly build up values, 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. Edit: And they are measuring two close but different things, the first two read the average over the total time, the third is the moving average of a 120 update window.

And a faster update rate on any of these configs ex.: Update=100 can get to a useable average much faster for most people who would use it in short bursts.
You do not have the required permissions to view the files attached to this post.
Last edited by Alex88 on August 7th, 2020, 7:49 am, edited 2 times in total.
User avatar
Active Colors
Moderator
Posts: 1251
Joined: February 16th, 2012, 3:32 am
Location: Berlin, Germany

Re: Config/Skin Resource Usage Tips and Discussion

Post by Active Colors »

Thanks for all the links Alex88. I have a question about what you posted.

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?

EDIT: updated the details of my question.
User avatar
Yincognito
Rainmeter Sage
Posts: 7151
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: Config/Skin Resource Usage Tips and Discussion

Post by Yincognito »

Active Colors wrote: August 7th, 2020, 7:32 am Thanks for all the links Alex88. I have a question about what you posted.

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?

EDIT: updated the details of my question.
Alex88 will no doubt answer this and share his view on this, but I'll share mine as well, if you permit. 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.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth