Efficient use of Meters and Measures

[TGonZo]

I have a couple of questions about reducing CPU resources when using Meters and Measures that do not update very often. I've read the Anatomy of a Skin and several other Getting Started sections in the Docs. I think I have a good basic understanding of how Rainmeter works, but still have a couple of detail questions to help make the Skins I create more efficient.

My example for my questions is a simple Weather skin. I understand the webparser has a default UpdateRate of once every 5 minutes, which is fine since most weather site only update data once every 5 minutes. But I have several other measures and many meters to display the data. If the webparser is only running once every 5 minutes, are the other measures and other meters still running once every second? Assuming default Update=1000.

If that is true, then is seems more efficient to either change the meters to also only update every 5 minutes, UpdateDivider=600. And/or also use a OnChangeAction in the measure to do a !UpdateMeter for the meter using that measure. Or change the whole skin to only update once every 5 minutes. I'm not sure why, but the last option does not seem like a good idea. If something doesn't update correctly, it is not fixed for 5 minutes.

I know it may not save much, but I have about 30 meters on the skin with a few non-webparser measures. I'm assuming they are all running once a second for 5 minutes with no data change. By making a couple of changes, I can get the meters to only run once per 5 minutes with the webparser. That seems better to me. 600 updates X 30 meters = 18000 updates of the same data. That seems a bit wasteful.

Also, any String Meter that is a label on a skin that does not change, should probably have the UpdateDivider=-1 in it, yes? No sense in continually updating a label that does not change.


I would think the developers would know this behind the scenes information better than most. So developers, what do you think? Would this actually make a skin use less CPU?

It seems that for many skins, the standard 1 second update is fine, but for a weather skin, it seemed way too often.

I've been using Rainmeter a couple of months now, and I could not find this topic discussed in the forum, and thought it would be good to bring up, and verify what I think is going on, to make sure I really am making my skins more efficient.

Thanks all.

[jsmorley]

I would just never use UpdateDivider at all with WebParser parent or child measures. All the real work is done by the plugin, and there is just no real benefit to trying to finesse that. You can really only risk "lag" between the value being returned by the plugin and it being used in the skin.

As to meters, That is up to you. Yes, if you have a meter that is "static", then you could use UpdateDivider=-1 on it, but honestly, the CPU you are going to save will round to zero, even if you have a hundred meters in the skin.

[killall-q]

Yes, if the only dynamic part of the skin only needs to update once every 5 min, then you can use Update=300000 on the skin and UpdateRate=1 on the WebParser. Mouseover/click effects and such are best done instantly on demand anyway via !SetOption+!UpdateMeter+!Redraw. That is essentially what I do in my Comics skin.

It's just usually advised against for new learners because if you mess up this advanced optimization, your skin just became a DDOS script, and the problem compounds if you distribute the skin. You may not realize there's a problem until a week later when you're wondering why the site is blocking your IP.

[jsmorley]

Yes, if the only dynamic part of the skin only needs to update once every 5 min, then you can use Update=300000 on the skin and UpdateRate=1 on the WebParser.

I entirely disagree with this.

There are cases, if you are using the value of a WebParser measure in a Calc measure or other formula, where that can cause a lag of up to 300000 milliseconds from the time that the data is obtained by WebParser and when it is "used" by the skin.

While it may work fine in your specific skin, I think it is a bad idea to encourage folks to use anything except UpdateRate to control WebParser, and just let the measures "update", in the normal skin update cycle sense, once a second.

[killall-q]

Yeah, this is a very advanced optimization. To have a skin update so slowly, you basically have to set up cascading chains of execution for everything in the correct order or some changes will show up 5 min late.

You just have to use FinishAction= on WebParser to !UpdateMeasure, !UpdateMeter, and !Redraw everything that's affected by the WebParser. You can also take a shortcut by executing a Lua function, as Lua won't be affected by the update rate of the skin. This is how I minimize display latency in my Guild Wars 2 World vs World Map.

[jsmorley]

This was a question by a new Rainmeter user, and I'm pretty sure he is trying to get a sense of whether optimizations are going to make a difference in resources used when he is working with WebParser. The answer is NO. The real work is done by the plugin, and the amount of CPU that Rainmeter uses to "update" a child WebParser measure once a second is just about as close to zero as you can get. Child WebParser measures literally do no work. They don't even "go and get" an answer from the parent WebParser measure. The plugin itself actually populates them.

I'm all for optimizing skins. I do so myself in every skin I ever write. I tend to focus on where it actually makes a difference though.

I'm not trying to pick a fight with you on this. Certainly carefully optimizing as much as possible isn't a "bad" thing. I'm just leery of putting more on a new user's plate than will really help them, particulary early on.

[TGonZo]

Thanks guys. I believe that was helpful. I do see the slippery slope if you "optimize" so much it starts causing problems. I certainly don't want that. I like simple with a little optimization where it is easy and makes sense.

So, my big takeaway is, you can optimize a lot of meters to only run when needed in those niche cases, but they are so efficient already, you are saving so little it is not worth the effort most of the time.

So, keep it simple, optimize a little where it make sense, and be happy.

Thanks guys.

BTW, Rainmeter is awesome!

[jsmorley]

Thanks guys. I believe that was helpful. I do see the slippery slope if you "optimize" so much it starts causing problems. I certainly don't want that. I like simple with a little optimization where it is easy and makes sense.

So, my big takeaway is, you can optimize a lot of meters to only run when needed in those niche cases, but they are so efficient already, you are saving so little it is not worth the effort most of the time.

So, keep it simple, optimize a little where it make sense, and be happy.

Thanks guys.

BTW, Rainmeter is awesome!

I think that is a fair assessment. Make no mistake, there are times when it really does pay to optimize skins, particularly with measures that do a lot of work, or really big complicated skins that you want to wring the last cycle of efficiency out of. As you go along, you will find times that carefully using UpdateDivider and bangs like !UpdateMeasure / !UpdateMeter / !Redraw will be a big help. Probably not so much with WebParser due to the nature of it.