Open ShapeMess opened 2 years ago
I'd happily invest some time in solving that issue if that's not a problem to other contributors, I don't want to introduce a yet another dependency to my current project and I don't expect any quick updates addressing this problem since small issues like this one tend to be low in priority.
Is your feature request related to a problem? Please describe. The
si.graphics
method used for checking GPU and display information can easily be used for monitoring certain parameters of installed graphics cards like usage and temps and displaying on them on graphs. This kind of usage tends to happen inside an interval or a loop. Meanwhile information like attached displays tends to be static unless somebody actually sawps the displays at run time. The issue is that while checking GPUs (through nvidia SMI) is not especially resource intensive - gathering display information causes over 10 short-lived threads to spawn, potentially choking the CPU (about 40% usage spike on a Ryzen 7 3700x and 70-80% on an I5-7500) plus 200-300MB of memory used which could potentially cause the host OS to move some memory to a paging file. This was tested only on Windows so far, although the task manager shows incorrect CPU usage it's still there. It's only read out incorrectly because the spike happens over such a short amount of time.Here's the difference between when a program is at idle and when systeminformation is gathering display information: The first two yellow columns are CPU and memory usage respectively. While the promise is pending:
Higher-end devices are not so vulnerable to high CPU/memory usage spikes but it could easily cause the computer to lag or freeze for a moment as other threads will fight over resources. On devices like the Raspberry Pi, other SBCs or older computers that could be a single reason for uninstalling whatever program makes use of this feature.
Describe the solution you'd like As of the version 5.x.x it'd be great to add a second optional boolean parameter placed after the callback function that defaults to true by which it would be determined whether or not to gather display data.
This way no breaking changes would be introduced and the default behavior wouldn't change except for how the internal logic would determine whether or not to use a callback or return a promise - maybe substitute the callback for null/undefined in case of promises?
For version 6.x.x I would suggest splitting
si.graphics
into two separate methods.Describe alternatives you've considered As of now my only alternative is extracting the code that makes use of the SMI and refactoring it to only gather GPU information.