[Bug?] UsageMonitor plugin error

[tjhrulz]

By the way, is it normal to have those UsageMonitor values at 0 for a couple of moments when loading Rainmeter? I don't recall it happening before - although I could be very well mistaken, since the skin stayed a for long time showing the static value of CPU usage before these tests (the walkthrough the aliases is more of a feature than something I personally use). I do remember the skin showing numbers like 1 or 2 (as the name of the top process) at Rainmeter load though, in the past, so it might be just a part of the normal "initialization" process...

P.S. No errors so far.

EDIT: One other thing I wanted to ask: the GPU alias is always 0 when dynamically walking through aliases once every second, and when I pause it to show the GPU top processes, only Rainmeter with a little more than 1% GPU usage is shown. Is this normal? Could it be because my GPU card (AMD HD 7610M, 1GB DDR3) doesn't support hardware encoding and thus less programs use the GPU? Even so, Chrome should definitely use it and be quite high on it, since it's taking up quite a bit of CPU as well when it starts.

Yes that is normal, to prevent Rainmeter from being blocked (aka doing nothing) while reading performance counters I just give Rainmeter empty data until the counters have updated, then on the next update of your skin it will read those counters now that they have been set up. These counters take a very long period of time to set up and update (EACH counter has an unavoidable ~100ms hit on EVERY update even on a decent CPU). So if no other skin is currently also reading that counter then it is going to take time to get everything set up and reading back data, this takes even longer to happen with GPU aliases due to us also needing to set up another counter so that we can translate the PIDs and Graphics Engine data into a human readable name. This is likely why that one is giving you issue due to it being a separate performance counter that has more work to set it up every time. Also GPU usage in from that data can seem odd like that, for example you will find even if you are GPU bound in a game that it likely will never hit 100% load. This is because frequently there are other things holding your FPS back besides raw compute such as memory transfer speed bottlenecks as well as some of that GPU cost that programs have is hidden in system apps that are frequently in blocklists like DWM, System, csrss, and several others that escape me at the moment.

I would recommend maybe the instead of scrolling through aliases on one measure make a different measure for each alias you want to use and scroll through the measure that the meter reads from. This should avoid you needing to use DV=1 and you data will also likely be more recent than what you have now. This also may fix your GPU stuff being 0 and likely will have a more consistent if not also a little bit better performance than before as I built usage monitor to share as much CPU cost as possible between measures, even if they are in different skins so having multiple measure is not an issue

[Yincognito]

Yes that is normal...

Oh ok, that explains it - thanks for letting me know.

I would recommend maybe the instead of scrolling through aliases on one measure make a different measure for each alias you want to use and scroll through the measure that the meter reads from. This should avoid you needing to use DV=1 and you data will also likely be more recent than what you have now. This also may fix your GPU stuff being 0 and likely will have a more consistent if not also a little bit better performance than before as I built usage monitor to share as much CPU cost as possible between measures, even if they are in different skins so having multiple measure is not an issue

I slightly disagree here. I employed reusable measures intentionally, to both make the code more compact (it does wonders in my Weather skin, for example, where instead of hundreds of measures I only have around 50 that get reused by means of DV and scrolling, and this is true for most of my other skins in the suite as well, bar the CPU skin, where I have to have measures for each logical CPU as those values are all displayed at the same time, unlike in the other cases) and save resources by having a reduced number of measures. It's good to know that you designed your plugin to handle efficiently the multiple measure scenario (didn't know that), so this could be an exception from the rule, but I'd have to weigh in the pros and cons of doing that in just one skin. I do put an emphasis on performance and efficiency, but not so much of having some small delay in measurements - as long as they're accurate and low on resources (which they are, bar the other programs being active scenario I talked about earlier).

I doubt your suggestion would fix the GPU stuff being 0 (it's not that it's 0, it's the fact that other than Rainmeter itself, the other programs never appear), since that happens even when there is no scrolling and the automatic walkthrough the aliases is paused. I think I have tested this in another skin just to make sure, and it was the same - that's why I mentioned that maybe some particularity of the GPU is the "issue" here. Ah, just recalled that I also looked in PerfMon itself and likewise, only Rainmeter was there consuming GPU.

[tjhrulz]

Oh ok, that explains it - thanks for letting me know.


I slightly disagree here. I employed reusable measures intentionally, to both make the code more compact (it does wonders in my Weather skin, for example, where instead of hundreds of measures I only have around 50 that get reused by means of DV and scrolling, and this is true for most of my other skins in the suite as well, bar the CPU skin, where I have to have measures for each logical CPU as those values are all displayed at the same time, unlike in the other cases) and save resources by having a reduced number of measures. It's good to know that you designed your plugin to handle efficiently the multiple measure scenario (didn't know that), so this could be an exception from the rule, but I'd have to weigh in the pros and cons of doing that in just one skin. I do put an emphasis on performance and efficiency, but not so much of having some small delay in measurements - as long as they're accurate and low on resources (which they are, bar the other programs being active scenario I talked about earlier).

I doubt your suggestion would fix the GPU stuff being 0 (it's not that it's 0, it's the fact that other than Rainmeter itself, the other programs never appear), since that happens even when there is no scrolling and the automatic walkthrough the aliases is paused. I think I have tested this in another skin just to make sure, and it was the same - that's why I mentioned that maybe some particularity of the GPU is the "issue" here. Ah, just recalled that I also looked in PerfMon itself and likewise, only Rainmeter was there consuming GPU.

Ah I misunderstood you, the way you said that I thought you were saying that it was broken only when doing the scrolling, if it is working the same with and without scrolling then you are good to go and there is no need to change anything.

But yeah I would say this plugin is the exception to the rule and definitely that recommendation would not be true for just about any other plugin. I just know how poorly people used the plugins that came before UsageMonitor and if I was going to build a threading system that would take the updates off the UI thread for Rainmeter to prevent the stutter that happened with those other plugins I figured I might as well build a monolithic system that made sure as much resources as possible were shared so that I effectively automated the parent child process that people were supposed to do (But did not) with those previous plugins and applied it even across skins which was not possible before causing significant performance gains

[Yincognito]

Ah I misunderstood you, the way you said that I thought you were saying that it was broken only when doing the scrolling, if it is working the same with and without scrolling then you are good to go and there is no need to change anything.

But yeah I would say this plugin is the exception to the rule and definitely that recommendation would not be true for just about any other plugin. I just know how poorly people used the plugins that came before UsageMonitor and if I was going to build a threading system that would take the updates off the UI thread for Rainmeter to prevent the stutter that happened with those other plugins I figured I might as well build a monolithic system that made sure as much resources as possible were shared so that I effectively automated the parent child process that people were supposed to do (But did not) with those previous plugins and applied it even across skins which was not possible before causing significant performance gains

Yeah, totally agree. I very much like your plugin's minimal impact on resources, you're a champion at that. The only thing I didn't like in your plugin was the fact that the near 0% processes were not shown (unlike in the plugins before it). But then, I eventually got used to it and I'm not in any way bothered by it anymore. And yes, I am aware and understand the technical explanation for that, I just had a different opinion on it initially, that's all. Now I just replace empty spaces with some default "no process" string and it's all good.

[tjhrulz]

Yeah, totally agree. I very much like your plugin's minimal impact on resources, you're a champion at that. The only thing I didn't like in your plugin was the fact that the near 0% processes were not shown (unlike in the plugins before it). But then, I eventually got used to it and I'm not in any way bothered by it anymore. And yes, I am aware and understand the technical explanation for that, I just had a different opinion on it initially, that's all. Now I just replace empty spaces with some default "no process" string and it's all good.

Yeah I actually was in the same boat as you originally on that and fought jsmorley for quite a while that we should at least have an option to show all processes even if they did not run at all during the last update but I did have to agree with his argument of how do we sort it when it is all 0 After hearing that I conceded that argument (Maybe I will have to sneak it in without him knowing )

[jsmorley]

I don't think the issue is with processes that are using zero CPU, they just don't exist as far as any logical list of process in the context of a performance monitor / usage monitor. What I think was being said was that processes that take "almost" zero, but not quite, CPU don't seem to show up.

[tjhrulz]

I don't think the issue is with processes that are using zero CPU, they just don't exist as far as any logical list of process in the context of a performance monitor / usage monitor. What I think was being said was that processes that take "almost" zero, but not quite, CPU don't seem to show up.

I mean in order for them not to show up they would have to be so small that they are less than the floating point precision that Performance Monitor has and thus would be 0 but ran an instruction. You can actually see this in Task Manager as after a certain point the 0% go from being in random order to alphabetical. The only way to "fix" that would be to show the 0% instances. I can look into maybe if we could write our own convert function but that is tough to say as there is a lot that goes into converting performance counters to the human readable versions, and well we would be chasing stuff so small we would be better of just showing the 0 values or ignoring it

[jsmorley]

I mean in order for them not to show up they would have to be less than 0.05 since performance monitor's conversion function only goes to one tenth accurarcy and thus they would round down to 0. You can actually see this in Task Manager as after a certain point the 0% go from being in random order to alphabetical. The only way to "fix" that would be to show the 0% instances. I can look into maybe if we could write our own convert function but that is tough to say as there is a lot that goes into converting performance counters to the human readable versions

Based on what I'm seeing, they don't show up if they don't "round" to 0.1

[jsmorley]

Based on what I'm seeing, they don't show up if they don't "round" to 0.1

I don't see this as a big deal, but I would be opposed to listing processes that are not currently using any CPU at all. You might have a hundred of those, and how do you order them in a skin with 10 meters? Random? No way, that would just be the most jumpy annoying skin ever. Alphabetical? So AArdvark.exe is always more important than Zippy.exe? We are measuring "usage" right? How does a process with no "usage" fit in that world?

[jsmorley]

I don't have a lot of skin in this game, and I'm ok with whatever you think best. For my own personal tastes, I like a skin displaying up to say 10 CPU processes ordered by amount to only include processes that are actually using CPU.

1.jpg

2.jpg