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
In short, this function gets the current process resident set size by using the resource library, but this library is only available on Linux. When run on Windows, this function simply returns 0, which causes the downstream callers to see this as an error and fail running the benchmark entirely.
I began working on a fork where I instead use psutil to get the current process' RSS, but I noticed that psutil.Process().memory_info().rss returns higher values than the measurements from the resource library. I'm seeing roughly 25% - 35% higher RSS size with psutil`, so that leads to a dilemma in terms of accuracy across operating systems. We have a few options:
psutil works cross-platform, but the rss values are not accurate with what the resource module gets. We can opt to only use psutil moving forward, but that would invalidate all existing command benchmark results until they are re-run.
We can use psutil only for Windows systems, but this leads to a memory usage discrepancy between operating systems. On my Mac Mini, the resource and psutil RSS sizes did not match by a wide margin, so for Windows systems it would falsely appear to have higher memory usage than Mac systems (and presumably Linux ones as well).
We can use some other data point, such as the Unique Set Size from psutil through psutil.Process().memory_full_info().uss. USS is closer to what the resource module gets for RSS, but now USS is about 15% smaller than RSS from the resource module. USS is supposed to be the closest representation of the process memory usage, which should be more ideal than RSS or peak RSS
I'm not aware of any other ways to get the memory usage of a process without writing some C bindings to do so. What's more confusing is that there is also the _win_memory.py file that uses Windows-native functionality to track memory usage, but from my testing that's not used correctly - if it was then I wouldn't be getting the above error.
I see in both _runner.py and _worker.py that we break down what method to use based on what OS is running. If we go with using psutil for the unifying the memory tracking of command benchmarks, should we do the same for regular benchmarks?
The text was updated successfully, but these errors were encountered:
HunterAP23
changed the title
Windows memory tracking fails
Windows bench_command memory tracking fails
Apr 23, 2025
Using psutil.Process().memory_info().rss on Windows sounds like a good idea.
What's more confusing is that there is also the _win_memory.py file that uses Windows-native functionality to track memory usage, but from my testing that's not used correctly - if it was then I wouldn't be getting the above error.
It's used by collect_metadata to set mem_peak_pagefile_usage metadata. I don't know how it compares to RSS memory.
Uh oh!
There was an error while loading. Please reload this page.
Creating a new issue to track a PR I'm working on to fix the issue in the title. Related issue from May 2021: #97
I was attempting to track the memory usage of command benchmarks on Windows, but got the following errors when doing so:
I debugged my way through the code and ended up getting the root cause, which is located here:
pyperf/pyperf/_process_time.py
Lines 25 to 42 in e0610c2
In short, this function gets the current process resident set size by using the
resource
library, but this library is only available on Linux. When run on Windows, this function simply returns 0, which causes the downstream callers to see this as an error and fail running the benchmark entirely.I began working on a fork where I instead use
psutil
to get the current process' RSS, but I noticed thatpsutil.Process().memory_info().rss
returns higher values than the measurements from theresource library. I'm seeing roughly 25% - 35% higher RSS size with
psutil`, so that leads to a dilemma in terms of accuracy across operating systems. We have a few options:psutil
works cross-platform, but therss
values are not accurate with what theresource
module gets. We can opt to only usepsutil
moving forward, but that would invalidate all existing command benchmark results until they are re-run.psutil
only for Windows systems, but this leads to a memory usage discrepancy between operating systems. On my Mac Mini, theresource
andpsutil
RSS sizes did not match by a wide margin, so for Windows systems it would falsely appear to have higher memory usage than Mac systems (and presumably Linux ones as well).psutil
throughpsutil.Process().memory_full_info().uss
. USS is closer to what theresource
module gets for RSS, but now USS is about 15% smaller than RSS from theresource
module. USS is supposed to be the closest representation of the process memory usage, which should be more ideal than RSS or peak RSSI'm not aware of any other ways to get the memory usage of a process without writing some C bindings to do so. What's more confusing is that there is also the _win_memory.py file that uses Windows-native functionality to track memory usage, but from my testing that's not used correctly - if it was then I wouldn't be getting the above error.
I see in both _runner.py and _worker.py that we break down what method to use based on what OS is running. If we go with using
psutil
for the unifying the memory tracking of command benchmarks, should we do the same for regular benchmarks?The text was updated successfully, but these errors were encountered: