You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
While trying to all of the information of all my processes in my Windows 10 PC using gopsutil.process, I observed about %40 CPU usage and ~38s runtime. After introducing go's concurrency and removing Cmdline() and IOCounters() calls which used most of the runtime, I was able to reduce it to about ~1.5s. However %40 CPU usage stayed. I did CPU profiling with pprof and found getFromSnapProcess was using the most resources. Right now it discards 2 of the 3 values (ppid, name and num threads) returned by a windows.ProcessEntry32 object in each call, which is found by iterating through all of the processess in the PC. This causes a O(3 * N * N) complexity while it is possible to iterate for once and keep the data for further calls with just a O(N) complexity with only a slight increase in memory usage.
Describe the solution you'd like
I wrote an external replacement function for getFromSnapProcess which keeps its data as a map with referencing:
I observed a drop in CPU from %40 to %2 while increasing total memory usage by about 20MB. Runtime also dropped from 1.4s to about 0.3s. However I don't have the time to prepare this for gopsutil at the moment. Therefore I wanted to add this as a feature request.
The text was updated successfully, but these errors were encountered:
This causes a O(3 * N * N) complexity while it is possible to iterate for once and keep the data for further calls with just a O(N) complexity with only a slight increase in memory usage.
Solution to this is probably #286, but then we would have to implement an API for cache invalidation, which is not straightforward.
Solution to this is probably #286, but then we would have to implement an API for cache invalidation, which is not straightforward.
How about a simple CreateTime() check for it instead? If it is created at the same time with the same pid then it is the same process. At least for Ppid and Name have to stay the same, only one that could differ is NumThreads. Perhaps this kind of logic could also be implemented for #286 where it would be more meaningful?
Is your feature request related to a problem? Please describe.
While trying to all of the information of all my processes in my Windows 10 PC using gopsutil.process, I observed about %40 CPU usage and ~38s runtime. After introducing go's concurrency and removing Cmdline() and IOCounters() calls which used most of the runtime, I was able to reduce it to about ~1.5s. However %40 CPU usage stayed. I did CPU profiling with pprof and found getFromSnapProcess was using the most resources. Right now it discards 2 of the 3 values (ppid, name and num threads) returned by a windows.ProcessEntry32 object in each call, which is found by iterating through all of the processess in the PC. This causes a O(3 * N * N) complexity while it is possible to iterate for once and keep the data for further calls with just a O(N) complexity with only a slight increase in memory usage.
Describe the solution you'd like
I wrote an external replacement function for getFromSnapProcess which keeps its data as a map with referencing:
https://golang.hotexamples.com/examples/syscall/-/Process32First/golang-process32first-function-examples.html
I observed a drop in CPU from %40 to %2 while increasing total memory usage by about 20MB. Runtime also dropped from 1.4s to about 0.3s. However I don't have the time to prepare this for gopsutil at the moment. Therefore I wanted to add this as a feature request.
The text was updated successfully, but these errors were encountered: