I’m observing the InputSystem taking an extremely long amount of time during Domain Reloads. This seems like a bug – is there a way to improve this, or should I file a report?
Is there an easy way to patch this in the source? I’m happy to dive into it and submit a PR.
Bump.
From the screenshot it looks like it’s the Mono JIT taking an unusually high amount of time – which is not what I would have expected. There’s some other bits during domain reload survival needing optimization and the usual suspect for me would have been a very complex HID wreaking havoc on the tardy InputDeviceBuilder&InputControlLayout paths but from the screenshot, that doesn’t quite seem like it.
Would you mind digging further down into that Mono.JIT branch and see where the majority of that time goes?
Forgot whether we’re nesting static constructors in there if the JIT triggers certain object creation. In that case, likeliest explanation is we end up hitting the device paths again and there’s some code that ends up pointlessly crawling through some HID with 10000 elements or something like that.
Also, would you mind grabbing a quick screenshot of the input debugger after reload completes with the “Devices” branch fully extended?
Hi Rene,
Thanks for the response! Here’s the fully expanded hierarchy, from a deep profile. This sounds absurd, but for some reason when I take a Deep Profile, the total time gets faster. On a non-deep-profile refresh it takes 1 second.
It looks like instantiating the layout is the slowest bit.
Here are the devices. They’re not listed, but I also have an Oculus Quest 1 plugged in, in Oculus Link mode with two touch controllers.
Thank you for the details! Very cool.
That profile looks way more than what I would have expected. And yup, clearly points to the layouts and device builder, as expected.
Could you give 1.1-preview.2 a try? Precompiled layouts landed in preview.1 and at least for the two major culprits (Keyboard and Touchscreen), these make a huge difference. On Touchscreen I saw a >22x speedup on device instantiation. Plus also big reduction in garbage being generated. I would expect that with preview.2, you should see a significant reduction in time spent here.
Unfortunately, precompiled layouts have their limits. I think we will still need to go in and significantly speed up InputDeviceBuilder and InputControlLayout operation. The flexibility inherent in these mechanisms IMO is really great but does come with a big performance penalty on device creation ATM.
Sounds good, I’ll give it a try when I have a moment (we have a few modifications on top of the package, so might be a few days to set aside a second to do it).
Do precompiled layouts currently only support a fixed set of devices? Would they be enabled for XR devices, or is there an easy workflow for generating them for an entire class of devices? I saw a brief tutorial on how to precompile a layout manually from the Unity UI, but I don’t know the set of devices we’ll need to support on launch. It’d be nice to have some way to just precompile all valid device layouts, even if it’s a little heavy.
Yup, there’s a fixed set (currently Keyboard, Mouse, Touchscreen, and PS4 Dualshock HID) coming as precompiled layouts with the package. Any layout can be turned into a precompiled one, though. ATM it’s a manual step. Right-click the layout in the debugger and choose “Generate Precompiled Layout”.
ATM not yet. One of the complications with XR devices is that, like HIDs, their layouts are dynamically generated. However, even those can be turned into precompiled layouts. Just a matter of setting it up.
There’s no way currently to easily generate them for an entire class of device. It’s a case-by-case kind of thing. Requires generating them with the manual step mentioned above and then registering them with InputSystem.RegisterPrecompiledLayout.
Wouldn’t be too hard to script something like that for a custom setup. Makes me realize, though, that we should really expose the entry point for that code generator just like we do for the action map one.
Gotcha, thanks for the info!
Man, it’d be great to somehow find a way to detect the needed devices, and precompile just those. And JIT generate the dynamic ones… 
Guess that wouldn’t work on iOS though.
