It is currently September 21st, 2020, 12:27 pm

[Bug?] UsageMonitor plugin error

Report bugs with the Rainmeter application and suggest features.
User avatar
tjhrulz
Developer
Posts: 252
Joined: October 13th, 2016, 1:28 am
Location: Earth

Re: [Bug?] UsageMonitor plugin error

Post by tjhrulz »

Yincognito wrote: August 7th, 2020, 8:47 pm That explains it, assuming that this is indeed what happens. Looking forward to see your updated version - hopefully it will still work with DV properly. I mean, there are cases when !SetOption just isn't feasible, as you might want to avoid having to update the measure / meter too soon and such, not to mention the !SetVariable bang is a bit shorter in length, so it's more comfortable too. :)
LOL. But yeah there are times where making it so you can use !SetOptions instead of just DV=1 is more hassle than its worth (And I will admit I have just DV=1 it in the past and figured if I needed the extra performance later I would fix it then).

But yeah my plan is to unofficially support DV=1 without issue just like before so you shouldn't have to worry about that. It has been running for about 2 hours which usually by then I would have a log with everything I have running so I am hopeful that I fixed it, if it is still good to go by the time the Penguins game is over and then Penguins win I will post it here :D
User avatar
pul53dr1v3r
Posts: 406
Joined: July 30th, 2014, 10:30 am

Re: [Bug?] UsageMonitor plugin error

Post by pul53dr1v3r »

Yincognito wrote: August 7th, 2020, 8:53 pm Me too, but DV is rarely going to produce a significant impact on performance, really. Obviously, I'm not talking about monster skins / skin suites that have other things coded inefficiently or a buch of other resources involved, as those will for sure feel the added pressure from DV. From what I can tell (hopefully I'm not mistaken), DV is only a "threat" to performance as an additional effect on other much worse CPU usage hogs.
i just "commented out" 30 useless DVs and can't notice any difference as far as the preformance are concerned, but if it has not any use in a meter/measure, i'd rather remove it. To shorten the code at least. :Whistle
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Bug?] UsageMonitor plugin error

Post by Yincognito »

tjhrulz wrote: August 7th, 2020, 8:56 pm LOL. But yeah there are times where making it so you can use !SetOptions instead of just DV=1 is more hassle than its worth (And I will admit I have just DV=1 it in the past and figured if I needed the extra performance later I would fix it then).

But yeah my plan is to unofficially support DV=1 without issue just like before so you shouldn't have to worry about that. It has been running for about 2 hours which usually by then I would have a log with everything I have running so I am hopeful that I fixed it, if it is still good to go by the time the Penguins game is over and then Penguins win I will post it here :D
Haha - excellent! Go Penguins!!! :HamseterDancer
^^Oops...those were not penguins, but ... penguins with fur on them, apparently. :lol:
User avatar
tjhrulz
Developer
Posts: 252
Joined: October 13th, 2016, 1:28 am
Location: Earth

Re: [Bug?] UsageMonitor plugin error

Post by tjhrulz »

Yincognito wrote: August 7th, 2020, 8:53 pm Me too, but DV is rarely going to produce a significant impact on performance, really. Obviously, I'm not talking about monster skins / skin suites that have other things coded inefficiently or a buch of other resources involved, as those will for sure feel the added pressure from DV. From what I can tell (hopefully I'm not mistaken), DV is only a "threat" to performance as an additional effect on other much worse CPU usage hogs.
It is more with measures/plugins that there are 5 phases that they go through, while I try to build them with performance no matter what in mind because I know how people use Rainmeter not everyone does that. So IMHO you should always avoid DV=1 wherever you can because even if it feels like you have to do a lot to prevent it, even the best built measure/plugin's cost of running the reload phase on every update likely has a worse impact, even if it is statistically insignifigant (Unless it requires LUA, then in which case DV=1 away) and for the worse case can be a very major difference (I have cut skins usage to 10% of what it what was before by removing DV=1 with some simple !SetOptions)

Phase 1: Initialize
Basically this is only run when a skin is loaded (Counter intuitively this is also run when a skin is reloaded since the skin has been unloaded and then loaded back in)

Basically this is for doing any setup that the skin needs before doing any work and allocate any data you need. You may also instantiate some of that data although sometimes you will do that during the reload phase, but for performance you want to do as much as you can here.

Phase 2: Reload
This is run right after Initialize on the first run and on any update cycle if DV=1 or the next update after !SetOption was run.

Basically this is where you are intended to read all the options for the measure. Given some measure have to cleanup after themselves before doing things again this is why DV=1 does not work on every measure because if they think that this can only run once per measure that is not the case. Depending on the measure this can have a mild or awful performance hit. Also note that this performance hit gets worse the more that measure is updated since this has effectively a "fixed" cost for every update cycle. You always want to do what you can in the initialize phase but because so much relies on the options of each measure it just is not possible to do most of the work before the reload phase

In the case of UsageMonitor this as is mild as it can be due to me always checking for if this measure was reloaded before but there are a lot of options to read as well as well as removing and then adding a instance from a dictionary and then cleanup from doing so it is likely a measurable amount (I have never measured it to know exactly how much)

Phase 3: Update
This is what runs every (Update*UpdateRate) ms

Basically this is where a measure is to do its work to update whatever its data is supposed to be, also it will return a number value that will be used any time the measure is referenced in a number fashion

Phase 4: GetString
This is what runs run EVERY TIME you get the string value of a measure

Basically this is intended to be just getting whatever the string value you would want to be returned for a measure from the work done in the update cycle. NOTE: YOU SHOULD AVOID DOING AS MUCH WORK AS POSSIBLE IN THIS PART. because this will be run every time a measure/meter requests the string value of a measure

Phase 5: Finalize
This is run only when a skin is unloaded (Counter intuitively this is also run when a skin is reloaded since the skin has been unloaded and then loaded back in)

Basically this is intended to clean up after you measure and unallocate in data that you allocated
Last edited by tjhrulz on August 7th, 2020, 10:42 pm, edited 1 time in total.
dvo
Posts: 970
Joined: February 7th, 2016, 6:08 am

Re: [Bug?] UsageMonitor plugin error

Post by dvo »

:Whistle nice job :welcome: :D
User avatar
tjhrulz
Developer
Posts: 252
Joined: October 13th, 2016, 1:28 am
Location: Earth

Re: [Bug?] UsageMonitor plugin error

Post by tjhrulz »

Alright even if the stupid penguins lost I figured I would be nice and post the new test version up here.

Also just because I want to know if it is possible for a certain edge case to happen that I thought could happen before but seems to not happen please let me know if you get a error in your log saying "This is not an actual error, if this happens let tjhrulz know this: " with some extra stuff on the end of the log
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Bug?] UsageMonitor plugin error

Post by Yincognito »

tjhrulz wrote: August 7th, 2020, 9:14 pm It is more with measures/plugins that there are 5 phases that they go through, while I try to build them with performance no matter what in mind because I know how people use Rainmeter not everyone does that. So IMHO you should always avoid DV=1 wherever you can because even if it feels like you have to do a lot to prevent it, even the best built measure/plugin's cost of running the reload phase on every update likely has a worse impact, even if it is statistically insignifigant (Unless it requires LUA, then in which case DV=1 away) and for the worse case can be a very major difference (I have cut skins usage to 10% of what it what was before by removing DV=1 with some simple !SetOptions)

Phase 1: Initialize
Basically this is only run when a skin is loaded (Counter intuitively this is also run when a skin is reloaded since the skin has been unloaded and then loaded back in)

Basically this is for doing any setup that the skin needs before doing any work and allocate any data you need. You may also instantiate some of that data although sometimes you will do that during the reload phase, but for performance you want to do as much as you can here.

Phase 2: Reload
This is run right after Initialize on the first run and on any update cycle if DV=1 or the next update after !SetOption was run.

Basically this is where you are intended to read all the options for the measure. Given some measure have to cleanup after themselves before doing things again this is why DV=1 does not work on every measure because if they think that this can only run once per measure that is not the case. Depending on the measure this can have a mild or awful performance hit. Also note that this performance hit because as a percent worse the more that measure is updated since this has effectively a "fixed" cost for every update cycle

In the case of UsageMonitor this as is mild as it can be but there are a lot of options to read as well as well as removing and then adding a instance from a dictionary and then cleanup from doing so it is likely a measurable amount (I have never measured it to know exactly how much)

Phase 3: Update
This is what runs every (Update*UpdateRate) ms

Basically this is where a measure is to do its work to update whatever its data is supposed to be, also it will return a number value that will be used any time the measure is referenced in a number fashion

Phase 4: GetString
This is what runs run EVERY TIME you get the string value of a measure

Basically this is intended to be just getting whatever the string value you would want to be returned for a measure from the work done in the update cycle. NOTE: YOU SHOULD AVOID DOING AS MUCH WORK AS POSSIBLE IN THIS PART. because this will be run every time a measure/meter requests the string value of a measure

Phase 5: Finalize
This is run only when a skin is unloaded (Counter intuitively this is also run when a skin is reloaded since the skin has been unloaded and then loaded back in)

Basically this is intended to clean up after you measure and unallocate in data that you allocated
Wow, thank you so much for your in-depth explanation on how DV work. :rosegift: I'm curious how much my skin suite could benefit from replacing DV with !SetOption, considering that on idle and without the CPU intensive Audio skin, the whole suite takes about half a percent of my 2.3 GHz CPU. Anyway, I will for sure be much more cautious now with DV, although it's a bit too late to correct all the instances in my skins as I would need to take it line by line on hundreds of them (lines, that is). I once had this ambition to avoid DV a any cost and UpdateDivider=-1 on everything I didn't need in a specific moment in time, but then came animations and other stuff I added and it became harder to follow that "regulating" pattern.

One question though, since you seem to be really familiar with how things work in Rainmeter: do you know why having other CPU/GPU "intensive" (or not that much) programs running alongside Rainmeter causes it to increase its CPU usage as well (something similar to a domino effect, pretty much)? Sure, I do have texts sliding endlessly in my skins and such, 3 of them (counting the Audio skin off as it's a special case, almost without any hope of improving more than it is now) updating every 25 ms, but it all goes well on idle, with 0.5% CPU average over 04:30 minutes. As sson as I open up Chrome or watch a YT video, the CPU usage of Rainmeter begins to rise as well. Can you guess what could be the problem, and if, say, DV are involved (I don't think so, but just to be sure)?
User avatar
tjhrulz
Developer
Posts: 252
Joined: October 13th, 2016, 1:28 am
Location: Earth

Re: [Bug?] UsageMonitor plugin error

Post by tjhrulz »

Yincognito wrote: August 7th, 2020, 10:52 pm Wow, thank you so much for your in-depth explanation on how DV work. :rosegift: I'm curious how much my skin suite could benefit from replacing DV with !SetOption, considering that on idle and without the CPU intensive Audio skin, the whole suite takes about half a percent of my 2.3 GHz CPU. Anyway, I will for sure be much more cautious now with DV, although it's a bit too late to correct all the instances in my skins as I would need to take it line by line on hundreds of them (lines, that is). I once had this ambition to avoid DV a any cost and UpdateDivider=-1 on everything I didn't need in a specific moment in time, but then came animations and other stuff I added and it became harder to follow that "regulating" pattern.

One question though, since you seem to be really familiar with how things work in Rainmeter: do you know why having other CPU/GPU "intensive" (or not that much) programs running alongside Rainmeter causes it to increase its CPU usage as well (something similar to a domino effect, pretty much)? Sure, I do have texts sliding endlessly in my skins and such, 3 of them (counting the Audio skin off as it's a special case, almost without any hope of improving more than it is now) updating every 25 ms, but it all goes well on idle, with 0.5% CPU average over 04:30 minutes. As sson as I open up Chrome or watch a YT video, the CPU usage of Rainmeter begins to rise as well. Can you guess what could be the problem, and if, say, DV are involved (I don't think so, but just to be sure)?
Replacing DV is not always worth it nor noticeable to an end user and I wouldn't tell someone they have to go back and "fix" their old skins to do not use it, especially when it comes at the cost of having time to work on new skins/updating old skins. But if you are looking for something to do there isn't any harm fixing it, especially because it really helps in gaining an understanding for how Rainmeter works.

Hmmm that is though to say and something I have not really seen myself. Task scheduling in windows is a very nebulous thing so it may have something to do with that. Also really with the way modern CPUs work figuring out a percent utilization is not an easy thing. This actually if I had to guess is the cause of adding all the processes from UsageMonitor added up can be over 100% when under heavy load because you CPU is actually processing more due to things like clock speed variance and SIMD instructions (Single instruction that outputs multiple data and takes several cycles). I don't know if you are seeing this in Rainmeter skins using UsageMonitor or in task manger's Main page or its details page, but this is something I want to add more ways to scale to 100% even though it wont be "accurate" but will at least look right to the end user. Given your computer has an older processor if you are looking at UsageMonitor's percent for Rainmeter and not Task Manager I could see this being more obvious to see than on my machine (Although it is pretty obvious on my machine if I do something like build Rainmeter.
Last edited by tjhrulz on August 7th, 2020, 11:06 pm, edited 1 time in total.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Bug?] UsageMonitor plugin error

Post by Yincognito »

tjhrulz wrote: August 7th, 2020, 10:46 pm Alright even if the stupid penguins lost I figured I would be nice and post the new test version up here.

Also just because I want to know if it is possible for a certain edge case to happen that I thought could happen before but seems to not happen please let me know if you get a error in your log saying "This is not an actual error, if this happens let tjhrulz know this: " with some extra stuff on the end of the log
There you go. It happened as soon as I let my Processes skin dynamically change the Aliases once every second (it was previously set to be static on the CPU usage). If I'm not wrong, I think I saw some 0 values in the skin for a very short time (I guess that's why I took a look at the Log afterwards).
UsageMonitor - Test 00.jpg
Hopefully you won't fix it for pul53dr1v3r only to ... erm ... "unfix" it for me, LMAO. Just joking, of course (I think). :???:
You do not have the required permissions to view the files attached to this post.
User avatar
Yincognito
Posts: 2565
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Bug?] UsageMonitor plugin error

Post by Yincognito »

tjhrulz wrote: August 7th, 2020, 11:03 pmGiven your computer has an older processor if you are looking at UsageMonitor's percent for Rainmeter and not Task Manager I could see this being more obvious to see than on my machine (Although it is pretty obvious on my machine if I do something like build Rainmeter.
Yes, I have a skin that shows the current CPU usage, average CPU usage and time interval measured for Rainmeter, and the measurement (actually, just one, the current one) is done through UsageMonitor.