balala wrote: ↑August 5th, 2020, 5:49 pm
Recommend not to set dynamic variables, only when needed. For instance on measures or meters using dyanmically set variables (variables set with !SetVariable bangs) or section variables. The measures or meters having options set with !SetOption bangs don't require to set dynamic variables.
Agree, and i'll have to recheck the code in search for the small mistakes.
pul53dr1v3r wrote: ↑August 6th, 2020, 9:03 pm
Agree, and i'll have to recheck the code in search for the small mistakes.
Don't misunderstand me: the code probably does work even with the added DynamicVariables option as well. They are just not needed and are increasing a little bit the CPU usage (even if not too much).
balala wrote: ↑August 7th, 2020, 7:49 am
Don't misunderstand me: the code probably does work even with the added DynamicVariables option as well. They are just not needed and are increasing a little bit the CPU usage (even if not too much).
I actually built it so it would not increase the CPU (Even though I never explicitly said DV is safe) because I know very few people know the !SetOptions trick. IT seems that actually may be the cause (It also is likely going to happen more in a heavy graphics skin) of the issue as once I switched my test skins to DV and loaded a few from modern gadgets I seem to have triggered the issue.
My bet is having ran through the code I passed the old instance by reference instead of by value when a measure reloaded. So that may be how it is becoming null as in the very rare chance that reload happens on a measure and then UsageMonitiors backhaul updates between that reload and a give GetString for that measure then the Instance would be null due to me improperly keeping the old instance the measure had last time.
I have fixed this in the code and also played it safe switching a few other cases of me passing by reference when I should be passing by value just to be safe. Running it through its passes now and hopefully will have one for you guys to test this evening.
tjhrulz wrote: ↑August 7th, 2020, 7:59 pm
I actually built it so it would not increase the CPU (Even though I never explicitly said DV is safe) because I know very few people know the !SetOptions trick.
Which !SetOption (not !SetOptions) trick did you think to?
balala wrote: ↑August 7th, 2020, 7:49 am
Don't misunderstand me: the code probably does work even with the added DynamicVariables option as well. They are just not needed and are increasing a little bit the CPU usage (even if not too much).
It's a golden advice that buries my sporadic carelessness. The performacne are one of the most important things i care for so i goes without saying how much such a thing is valuable.
tjhrulz wrote: ↑August 7th, 2020, 7:59 pmMy bet is having ran through the code I passed the old instance by reference instead of by value when a measure reloaded. So that may be how it is becoming null as in the very rare chance that reload happens on a measure and then UsageMonitiors backhaul updates between that reload and a give GetString for that measure then the Instance would be null due to me improperly keeping the old instance the measure had last time.
I have fixed this in the code and also played it safe switching a few other cases of me passing by reference when I should be passing by value just to be safe. Running it through its passes now and hopefully will have one for you guys to test this evening.
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.
balala wrote: ↑August 7th, 2020, 8:23 pm
Which !SetOption (not !SetOptions) trick did you think to?
Well !SetOption effectively is the same as if dynamic variables was set for one update cycle. Thus if you know when something is going to change for a measure you can just set options it and get the same effect. Now there sometimes will be some quirks where you'll need to make sure that an option is set as the variable itself and not the value of the variable or else it won't update without having changed that option as well. But if I were to write a how to optimize a skin 101 this is pretty much your first thing you can do as almost 100% of the time that can be used instead of dynamic variables, and the performance is usually significantly better.
This is actually my number one thing I critique skins on that are posted in the rainmeter discord
pul53dr1v3r wrote: ↑August 7th, 2020, 8:45 pm
It's a golden advice that buries my sporadic carelessness. The performacne are one of the most important things i care for so i goes without saying how much such a thing is valuable.
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.
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
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.
