[Windows] net_io_counters() performance

[prutschman-iv]

Summary

• OS: Windows
• Type: performance

Description

I was troubleshooting a CPU usage issue in Dask dask/distributed#9161, and noticed that its usage of psutil.net_io_counters() was inducing nontrivial CPU load in the "Service Host: DNS Client" task. (Each Dask worker is calling this at least once a second, which is turning out to add up to something non-trivial on a many-core machine)

I traced this to the use of GetAdaptersAddresses in psutil_get_nic_addresses. Experimenting with this interface, I determined there are a few opportunities to speed this up, with differing orders of complexity, some anticipated by #1426

I made a CLI utility to make the same sequence of syscalls as psutil.net_io_counters, to benchmark. The base version calls GetAdapterAddresses once to get a buffer size, then again to fetch data. Then it calls GetIfEntry2 for each interface (of which there are maybe a dozen on my machine).

These are the optimization "phases"

Base version: 6.6 msec.
Skip flags: 2.8 msec.
Skip flags & remember size: 1.6 msec
Cache all interfaces: 0.5 ms (Possibly too aggressive)

First, there are flags that can be provided to GetAdaptersAddresses to skip the collection of various information. I tested with GAA_FLAG_SKIP_DNS_INFO | GAA_FLAG_SKIP_UNICAST | GAA_FLAG_SKIP_ANYCAST | GAA_FLAG_SKIP_MULTICAST | GAA_FLAG_SKIP_DNS_SERVER which skips all the skippable options except the friendly name. This may render it incompatible with other uses of psutil_get_nic_addresses, so it might be necessary to take an input parameter to indicate whether the full information should be collected. But this is a big win.

If we remember the buffer size from the first call to GetAdaptersAddresses we can re-use it, and it will almost always be correct, differing only when a new interface appears. This means we only call GetAdaptersAddresses once per call, instead of twice, which helps a fair bit. (And if it does change, we'll still detect this and update the cached size, we won't miss any interfaces).

If we remember all the interfaces and don't call GetAdaptersAddresses at all, we get an even bigger speedup. This was suggested as a future optimization in #1426 but it means not detecting new interfaces when they come up, which changes the semantics since new interfaces won't be noticed.

[giampaolo]

I'd have to go through #1426 first, but changing semantics looks like a bad idea. Better not to cache GetAdapterAddresses and get a correct (updated) result instead. Does calling it twice make a huge difference? Where is most of the time being spent?

[giampaolo]

I updated my previous comment.

[prutschman-iv]

I agree that changing the semantics isn't a good idea; I wouldn't have even suggested it except that it was mentioned as a possibility in the other issue.

About 90% of the time is spent in the two calls to GetAdaptersAddresses, about 3 msec per call in my test. Calling it only once almost doubles the speed, from ~6.6 ms => ~3.5 ms. Adding the skip flags stacks with that optimization, again almost doubling the speed, from ~3.5 ms => ~ 1.7 ms.

(I'm only running these for 5000 iterations, so there's probably some noise in there. The numbers are maybe good to 0.25 ms or so? And this is on my machine that happens to have a bunch of network interfaces.)