Library performance is significantly different between drivers/operating systems

Describe the bug

This came up while testing #914. It looks like the Windows tests are generally significantly slower than the linux tests. Generally, some operations are a lot slower than what they should be. For instance, the relatively simple PinValueReadAndWrite test takes between 1ms and 12ms (depending on driver) on linux and 23ms on Windows. It should not take more than 300 cycles, so 1ms is acceptable, everything else probably not. The test FastInterruptHandling even takes 3800ms on Windows, while it takes the expected 2100 on Linux (all drivers).

Steps to reproduce

Look at the build logs (two attached)

Expected behavior

• Tests take the expected amount of time (mostly given by any explicit delays).
• The same tests should take about the same time, regardless of OS or driver.

Actual behavior

See description. Timing is greatly dependent on OS and driver.

Versions used

The comparison was done with the test results from the Helix pipeline.

Note: Attached files are xml, but github doesn’t allow that directly.

testResults - Windows.xml.txt testResults - Linux.xml.txt

[Ellerbach]

@pgrawehr if you are looking for something on a real Windows (not Iot), a normal 32/64 bit version, you may have a look at using an FT4222, see https://github.com/dotnet/iot/tree/master/src/devices/Ft4222. Performance seems all ok, now there are couple of limitations because it’s working over USB, but it really works well. Support for MacOS is coming as well. There was a bug in the FTDI binaries which is fixed now. I’m just waiting for them to publish the fix to update the documentation. On the limitation side, if you’re interested in GPIO, all sensors in the repo detect automatically the driver. As FT4222 does not detect automatically, you’ll have to adjust the source code of the sensor you’re interested in to pass the GPIO driver at contruction. Feedbacks welcome if you’re interested in this approach as well.

[pgrawehr]

I’m completely aware of this, and I know that PInvoke calls may be expensive, but something in the order of 10ms for a call (from a rough estimate) would be really bad.

If the result of the investigation is that this is due to some OS limitation, I’m fine with that (maybe document it), but at this time, it looks like something is fishy. I have seen quite a few questionable Sleep()'s while investigating the interrupt performance issues.