-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report CPU usage by core #42
base: master
Are you sure you want to change the base?
Conversation
Thanks @MathiasMagnus! CPU-usage by core is definitely something that should be added into NTop. Actually I worked on this a while back: https://github.com/gsass1/NTop/tree/multiple-cpus, albeit instead of WinRT I used the PDH. I'm not too sure if what I wrote even worked though. Right now I can't work too much on NTop, mainly because I don't have enough time and I barely use Windows for development anymore. But if only hooking up the loads to the UI is left, then I can work on that in the following days. Then when that's done we can discuss WinRT vs PDH. |
@gsass1 Thanks for pointing to your working branch. AFAICT the only thing left is hooking the info up to the UI. The provider in this PR is WMI (Windows Management Infrastructure) which is an API to control/query just about anything on the system. WMI reads the CPU load as seen by the kernel. My implementation is sub-optimal in the sense that every refresh it creates a new enumerable query using WQL (Windows Query Language) which is a subset of SQL limited to queries only. I would expect WMI to do some kind of caching and if I query the same thing over and over again, it's not going to parse the WQL string again and again. The more optimal way is to create a refresher object which subscribes to some metric (CPU load eg.) and a refresher object means that this metric will be queried over and over again. However, refresher objects seem to only have For the time being, this works (see the console application in the PR which does nothing just spews core loads to the console). In the long run I'd like to convert the query to use |
@gsass1 I've seen you haven't pushed new work to your working branch. Just wanted to let you know I started tinkering with both displaying the info and reducing CPU load by moving to |
Hi guys, is it possible to add the feature to report to GPU as well? |
It is, I've already tested how to do it and it's working, albeit it's a bit more tricky. Because the project really looks discontinued I started writing one from scratch aiming for ftxui for easier rendering, but haven't gotten around to finishing it yet. |
Because nobody seemed to get the ball rolling on this (and it would be mighty useful) I thought I'd get things going by doing part of the work, hoping others will pick up the other, seemingly more involved part: hooking the info up to UI. This draft PR addresses #9.
If you would like to see this feature happen, please tune into development
Per-core CPU load reads on Windows AFAIK is only available through WMI, which is a C++ API. While WMI may be operable from COM alone, that's like flying an X-Wing blindfolded, which I don't intend to do. For the purpose of enabling per-core reading (and later GPU readings, which was also requested) this implementation adds a C++ translation unit exposing a C API.
Notes:
/permissive
flag added to the C++ source file is a temporary workaround to a bug in C++/WinRT, generating non-strictly ISO C++ headers. This should be fixed in a future version of the Windows SDK.main.c
.option
handling as opposed to imperative branching.Call to action
If someone is interested (either @gsass1 or anyone else) in hooking this information up to the UI, which too is a non-zero amount of work, help push it through the finish line. I did this part, because I saw that obtaining this info was non-trivial (to say the least) and if this was blocking people from making it happen: now it's done.