Performance of NetworkInterface methods on Windows

[DiCroce, Richard]

Hi everyone,
I'd like to propose a patch to fix a performance issue with enumerating network interfaces on Windows. The problem stems from the fact that getAll calls createNetworkInterface for every interface, but does not pass the list of interfaces that it has already collected. As a result, createNetworkInterface gets the entire list all over again.

When the number of interfaces is large, this can become very slow. On my machine, there are almost 100 "interfaces" (most of which are really filters). With the current code, a call to NetworkInterface#getNetworkInterfaces() takes ~600 ms. My patch cuts it down to ~15 ms.

This is the first time I've tried to contribute to OpenJDK, so I'm looking for someone to guide me through the process of getting this patch merged. I've already gotten The Powers That Be at my company to sign the OCA.

I'd also like to get your thoughts on a possible second patch that would be more extensive and might contain some functional changes. The current code is a little messy and uses some ancient APIs. Some initial experiments suggest that newer APIs (available since Vista/Server 2008) would be faster. The current code also invents its own interface naming scheme. Windows now has APIs for that (e.g. ConvertInterfaceLuidToNameW), but switching to those would obviously mean that getName() would return a different value than it does today. getByName() would also need to be adjusted, but I could code it such that it tries the Windows APIs first and then falls back to the existing code, in order to minimize breakage. So, given those caveats, do you think such a patch would have any chance of being accepted? Or would any breaking changes be a no-go?

Thanks,

[Logo  Description automatically generated]<http://www.scientificgames.com/>
Rich DiCroce
Senior Advanced Solutions Architect

Scientific Games



HAVE FUN. DO GOOD. PLAY HEALTHY.
May be privileged. May be confidential. Please delete if not the addressee.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230207/b29f92cc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17733 bytes
Desc: image001.png
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230207/b29f92cc/image001-0001.png>