I would be interested in seeing the impact on performances. Could you please measure it before and after the patch and paste the result?

python -m timeit -s "import psutil; p = psutil.Process()" "p.memory_info_ex()"

...also, while we're at it, is it possible to provide also PSS stats?

before (master):

python -m timeit -s "import psutil; p = psutil.Process()" "p.memory_info_ex()"
100000 loops, best of 3: 2.17 usec per loop

after:

python -m timeit -s "import psutil; p = psutil.Process()" "p.memory_info_ex()"
10000 loops, best of 3: 113 usec per loop

So slower, but not as slow as on Linux.

Any idea how to determine PSS?

I do not know of a method for calculating PSS on OSX.

Sorry for replying late. I was looking back at this and I wonder how this relates to Proces.memory_maps(). Currently memory_maps() implementation on OSX provides a "private" field. As such we should already be able to determine USS by doing:

>>> sum([x.private for x in psutil.Process().memory_maps()])

...but on the other hand the way you are determining USS (I'm talking about the implementation) is completely different. What's the difference between sum([x.private for x in psutil.Process().memory_maps()]) and psutil.Process().memory_info_ex().uss results? Are they equal?

I found this:
https://gitlab.phusion.nl/passenger/temp-passenger/blob/99bf9b590e2a5c3620d5fc34f540b749452448ca/ext/common/Utils/ProcessMetricsCollector.h#L381
...and here the same operation is referenced as "PSS" not "USS". Weird...

What's the difference between sum([x.private for x in psutil.Process().memory_maps()]) and psutil.Process().memory_info_ex().uss results? Are they equal?

They are not equal, memory_maps seems very low:

>>>print p.memory_info_ex(); print sum([x.private for x in psutil.Process().memory_maps()])
pextmem(rss=7880704L, vms=2534256640L, pfaults=9531392, pageins=1564672, uss=5849088L)
622592

The primary difference I can tell is memory_maps uses vm_region_recurse_64 and skips all submaps.

I found this:
https://gitlab.phusion.nl/passenger/temp-passenger/blob/99bf9b590e2a5c3620d5fc34f540b749452448ca/ext/common/Utils/ProcessMetricsCollector.h#L381
...and here the same operation is referenced as "PSS" not "USS". Weird...

They seem to be calculating some sort of USS/PSS hybrid.

@giampaolo Thanks for the review, I'll update per your style requests and merge into the main file.

@giampaolo Updated per requests, I think I covered everything:

• 4 spaces, foo_bar naming, // for comments
• Moved impl into _psutil_osx.c, renamed psutil_proc_memory_uss, exported in cext
• Added function level docs
• Use cext.proc_memory_uss to add uss to memory_info_ex result

If all is good I'd recommend squashing before merging if that's not in your standard workflow.

What do you mean by that?
On Feb 3, 2016 9:19 PM, "Eric Rahm" [email protected] wrote:

@giampaolo https://github.com/giampaolo Updated per requests, I think I
covered everything:

• 4 spaces, foo_bar naming, // for comments
• Moved impl into _psutil_osx.c, renamed psutil_proc_memory_uss,
  exported in cext
• Added function level docs
• Use cext.proc_memory_uss to add uss to memory_info_ex result

If all is good I'd recommend squashing before merging if that's not in
your standard workflow.

—
Reply to this email directly or view it on GitHub
#745 (comment).

@giampaolo I pushed an update that covered your code review changes, just wanted to list out what I changed and make sure you noticed.

Merged. Thanks a lot for this (I'll also update CREDITS).

The primary difference I can tell is memory_maps uses vm_region_recurse_64 and skips all submaps.

This made me think of #289.
If you understand the issue maybe you could fix memory_maps so that it takes submaps into account?