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
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.
