As per title we are experiencing huge CPU overhead when the input system is getting mouse movement events.
What can be the cause of this? Deep profiling seems to go deep (no pun intended haha) into unity’s code so is it possible a bug/mis-optimization? (There is no error message or anything logging either)
Here is a screenshot of our profiler. Note that deep profiling is enabled so the execution time is exagerated.
However profiling an actual build still shows a 0.20-0.50ms overhead just from moving the mouse around. On some of our test systems with lower end CPUs this leads to huge frame drops when moving the camera which is unacceptable for a first person game. We’ve noticed drops from 60~ to 40~ fps on some of our low end test platforms just from looking around in first person mode which makes no sense for a game.
So what would be the solution for this? We just changed from legacy input to this some months ago to facilitate in-game user binding and better controller support. Do we have to change again to some 3rd party solution or is there something we can do to solve this?
For reference, input system 1.0.1 (1.0.2 doesnt seem to have anything related to it in its changelog either so we didnt upgrade yet), Unity 2019.4, and this is what we’re polling from input system in our character controller:
Maybe setting up the actions in a different way would make a difference? We are currently using separate actions for mouse X/Y to facilitate the upgrade in our code (we had them like that from input.mouse scattered accross many places in code and we tried to replicate that API rather than refactoring most of our code base in terms of controls)
Please, first rule of measurement in unity: you don’t measure unity. You really need to measure things in a release build but at least in debug build. Do you get the same results in a build or you’re just measuring the editor?
It is a very bad idea to rely on data coming from the editor, the editor itself is a resource hog (naturally, the sheer amount of things happening in it), but also, if you use any 3rd-party assets and just one has something funky in it, you’re measuring that asset.
Oh man, it is embarrassing, I’m so sorry about that, somehow I missed half of your post even it is poking out my eyes now.
I’m not sure about actual solution since I dropped polling the minute the new system came out and I never had any problems with the action-callback part. Although I never measured it specifically (since never had any outstanding problem with it).
I remember there was a major problem performance-wise when people used high polling rate mouse with the new input system. But that should be fixed since the 2019.2 beta cycle if I remember correctly.
The best I can tell is the usual: try to build a test rig, empty scene with your polling mechanism and check if it is still there and then submit a bug report.
Didn’t know about the issue with polling and new input system, maybe a regression happened at some point? We’ll try to isolate it and see if polling rate affects it first, then we will see from there.
