Using GameInput adds big Timer event overhead to AIR app execution

When using GameInput by merely referencing GameInput.numDevices, an overhead of about 38ms for internal Timer event execution is added to Flash player once every second.

I have a "sandbox" AIR 3.8 Flash project that does nothing other than trace some properties to the console. Execution of this sandbox in Adobe Scout (with a non-debug SWF, using advanced-telemetry, and with all unnecesary options disabled to avoid overhead) looks like this:

It's all well and good. However, the mere addition of trace(GameInput.numDevices) once changes the execution radically. The result is this:

Every second, there's a ~38ms event overhead. Apparently, after the first reference to numDevices, the player starts checking for device addition/removal once per second, but it takes some time to do so (again, no other code is being executed).

To be fair, I'm not sure exactly of the impact of that in actual execution. Apparently, it's only adding 6ms to the time it takes to go from ENTER_FRAME to EXIT_FRAME. But even if that's the case, with a budget of ~17ms per frame, that's considerable overhead.

This was tested on a PC with Windows 7. Player/Air version was WIN 11,8,800,88. No devices were actually attached to the computer.

I haven't tested with Android/OUYA. I know GameInput works, but I haven't been able to test if the overhead is there.

I can provide more details, but it should be easy to reproduce on its own. All you need is a reference to GameInput.numDevices.

My question is: is this expected or is it part of something that's still being worked? The addition of the GameInput API to the desktop version of AIR is most welcomed, but a potential 223% execution budget overhead on a frame once every second is potentially disastrous for games since it'd mean constantly skipping frames.