Performance of NetworkInterface methods on Windows

[Daniel Jeliński]

Hi Richard,
welcome to net-dev!

I'm sure you noticed already that the createNetworkInterface is only
called when you set the system property java.net.preferIPv4Stack to
true, or when you are on Windows 95/2000. In all other cases your code
will use createNetworkInterfaceXP, which was fixed in JDK-14, see
https://bugs.openjdk.org/browse/JDK-8225239.

If you're only interested in having that fix in JDK 8/11, check
https://wiki.openjdk.org/display/JDKUpdates/JDK11u. If you're still
interested in working on createNetworkInterface, read on.

Going forward, we would want to keep only one implementation for each
method, i.e. remove the non-XP methods, reimplement IPv4Stack using
the XP methods, and remove the XP suffix. This would leave us with
only one implementation to maintain. Spending any effort on improving
the current non-XP version is probably a waste of time.

I'm not sure if the next JDK release will support Win8, or if we only
support Win10+ these days, but I'm pretty sure you can use the APIs
available in Win8.

HTH,
DJ


wt., 7 lut 2023 o 21:06 DiCroce, Richard
<Rich.DiCroce at scientificgames.com> napisał(a):
>
> 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,
>
>
>
> 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.
>
>
>
>