12x faster implementation for Mac OS #32
Conversation
|
Thanks a ton for this!
I'm thinking that we should make If it becomes an issue we could perhaps break out this gem into another micro gem that does not require FFI and does not have this optimization.
That is a concern for me, we could maybe introduce a method that returned both results and let people check their own systems. I'm going to take your patch, make FFI required and try to get Travis working with OSX. Thanks again for the patch, you rock! |
schneems
changed the title
Currently when you call `GetProcessMem.new` with a different pid value than the current process it calls `GetProcessMem::Darwin.resident_size this uses FFI to get data from the mach kernel about the current process. - #32 - https://stackoverflow.com/questions/18389581/memory-used-by-a-process-under-mac-os-x/23379216#23379216 This PR adds a test to ensure that memory results from different processes is correctly reported. This PR addresses the different PID problem by checking if a different pid other than Process.pid is being passed in. If that's the case then we will fall back to determining memory based off of shelling out to `ps`. There was a performance concern over using `Process.pid` but it appears to be relatively fast. It is approximately the speed of allocating 3 string object.
|
There's a bug reported where different PIDs don't return the correct information. I've got a workaround and a test in #41. It detects this scenario and then falls back. Do you have any ideas on how to pull task info from different processes from mach? |
Currently when you call `GetProcessMem.new` with a different pid value than the current process it calls `GetProcessMem::Darwin.resident_size this uses FFI to get data from the mach kernel about the current process. - #32 - https://stackoverflow.com/questions/18389581/memory-used-by-a-process-under-mac-os-x/23379216#23379216 This PR adds a test to ensure that memory results from different processes is correctly reported. This PR addresses the different PID problem by checking if a different pid other than Process.pid is being passed in. If that's the case then we will fall back to determining memory based off of shelling out to `ps`. There was a performance concern over using `Process.pid` but it appears to be relatively fast. It is approximately the speed of allocating 3 string object.
|
Well there is task_for_pid() which does what the name suggests but apparently you need elevated privileges for that (http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/) since you can use that for injecting code into a process and so on. I suspect another approach is needed. One starting point might be the source code to |
For context see #31.
This implements the approach mentioned here: https://stackoverflow.com/a/23379216/147390
Not sure about the platform selection logic - should using this codepath by compulsory for macs or should it fallback to the
psversion ? (but then how would people ever know to install ffi)This seems to produce the same results in my testing as
ps, is it worth trying to enforce that in specs ?Lastly, not sure what needs to go into .travis.yml for specs to run against the same set of rubies but on mac os.