Help Wanted EarlyUpdate.XRUpdate taking about 75% of main thread cpu time. Is this normal?

For the past couple months I've been having a very weird issue with the XR Plugin Management (3.2.10) when using the Oculus XR Plugin (1.3.4) in 2019.4.1f1 (and every stable build since May 2020), wherein the EarlyUpdate.XRUpdate has been take up around 75% of the main thread's CPU time for no apparent reason.

This is happening for me even with empty projects with just a basic XR Rig.

Dose anyone have any clue as to what's happening with this call? It's not actively causing me any errors... but it's like ominously ticking black box, which I can look into, and it is bombing my project with bad performance.

All that I can find anywhere about EarlyUpdate.XRUpdate is a singe line from the documentation: ("Native engine system updated by the native player loop.") From:
https://docs.unity3d.com/2019.3/Documentation/ScriptReference/PlayerLoop.EarlyUpdate.XRUpdate.html

(View photos for timing details.)
In standalone it's taking around 8 ms of execution time (out of my budgeted 11 ms for 90 HZ). In standalone the execution time for the EarlyUpdate seems to be trying to locking the time of each frame to fill out the full 11 ms between frames, which is fine... basically it's acting like a non-optional VSync which I can't turn off. Is this guess at all accurate for why it's taking so long? Is it waiting for a callback from the Oculus app with the new frame's headset and controller info?



What confuses me most about this is that in-editor it's taking around 3 ms. It's bizarre to me that it would be over 2.5x faster with profiling on in-editor. Also I can't for the life of me figure out why it is giving still be giving me a horrible 3 ms execution time in editor; when the editor loop itself is just as long as an entire 11 ms VR frame, which should mean that there are at least two frames worth of VR input data for every in-editor update call (no need to wait the 3 ms).... What am I missing here?




The problem isn't too much of an issues for me at this point as I use just a couple MS for both scripting + rendering my project with HDRP at this point, but having 75% of my CPU budget going just to XR's under-the-hood/no-peaking-at-what-its-doing-with-deep-profiling mystery update call is driving me crazy and I'm a bit afraid that it's going to put me under impossible timing restrictions of just have 2-3 ms to do all of my scripting and rendering work in the next couple moths as I start to develop the visuals for my game.

 

Hi @colinleet
I have the same problem. Did you solve it?

 

Nope. I'm still completely stumped by this, do you think we should report it as a bug? It's just SO BAD. Yet it doesn't seem to have any reasonable explanation that I can fathom, and it technically isn't producing any unexpected behavior other than being slow as hell. Turning off XR entirely makes the problem go away (of course), but I can only do that for short programming testing stents. My game's core design is exclusively VR. I'm tempted to see if this persists with OpenVR to see if it's just a platform dependent bug, as OpenVR can still be used on Oculus, but I want to keep support for Oculus naively as well. Have you tried it with OpenVR or any other XR platforms?