Skip to content
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

Combine Process .Ppid(), .Name(), NumThreads() for Windows #818

Open
AtakanColak opened this issue Jan 15, 2020 · 2 comments
Open

Combine Process .Ppid(), .Name(), NumThreads() for Windows #818

AtakanColak opened this issue Jan 15, 2020 · 2 comments

Comments

@AtakanColak
Copy link
Contributor

AtakanColak commented Jan 15, 2020

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.

@Lomanic
Copy link
Collaborator

Lomanic commented Jan 16, 2020

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.

#186 would also apply.

@AtakanColak
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants