[WLT] AnachorManagerXR accounts for 30% of app's cpu usage

[AMollis]

WLT's "XRSDK Anchor Manager" appears much more expensive than the equivalent "AR Foundation Anchor Manager". WLT's AnchorManagerXR consumes about 30% of the app's cpu usage.

The attached trace was gathered from an app using WLTs:

[fast-slow-still]

This sounds like #227

You can see in the profile you captured that all of the WLT time is spent in updating the OpenXR Plugin. WLT should not be calling update on the session subsystem on Android or iOS.

Can you provide version info for WLT, Unity, and XRSDK, as well as target platform? Thanks.

[fast-slow-still]

I had a closer look at the trace. I don't think this is the same issue as #227.

All of the time is spent in xrAnchorManager.GetChanges().

The XRSDK system is an inherently polled system. Calling GetChanges is necessary to retrieve the current state.

The AR Foundation system is event driven. I can only speculate, but it is easy to imagine that the event based system might incur less frame to frame overhead than the polled system.

Certainly, one would expect the distribution of time to be different. To fairly compare performance between the two systems, you would need to aggregate the time spent in (ARFManager's Update) + (AR Foundation's time processing ARAnchors) and compare that with AnchorManagerXR.Update.

I would still be interested in the version/platform info requested above.

[AMollis]

Also note, switching to AnachorManagerARF removed the CPU overhead we observed

The issue with AnachorManagerXR was observed on:

• HL2
• ARM64
• Unity 2020.3.19f1
• com.unity.xr.openxr 1.2.8
• com.microsoft.mixedreality.openxr 1.0.3

If this version of the anchor manager can't be fixed, then we should either remove it,and rely on AR Foundation anchor manager. Or at least document a strong warning against using AnachorManagerXR

[fast-slow-still]

You've only described more time being spent in the AnchorManagerXR than the AnchorManagerARF. I've tried to explain why that isn't an accurate comparison. AnchorManagerXR performs work that is done outside AnchorManagerARF.

I am not seeing reduced performance under AnchorManagerXR versus AnchorManagerARF at the application level. The performance trace you reported is as expected. If there is a performance problem with AnchorManagerXR, the profile you provide doesn't show it.

Thanks for providing the additional information.

[AMollis]

@fast-slow-still We should still investigate what is going on here. In the partners scenario there was an obvious performance hit using AnchorManagerXR. The partner's scenario involves walking the entire floor of an office building, and doesn't occur until using the app for > 20 min. Have you tried this?

I understand the technical reasons as to why there could be a perf hit. However, the problem is that this performance hit will not be obvious to other developers. So WLT needs to do one of the following....

(1) Prevent the performance degradation when using AnchorManagerXR for long sessions in large spaces. (2) Document the draw backs of using AnchorManagerXR and warn the developer of the negative impacts. (3) Remove AnachorManagerXR all together, since there is an alternative (i.e. If the developer is using XRSDK, they have access to AR Foundation)

[AMollis]

@fast-slow-still Can you please re-active this issue? Per my previous comments?

[fast-slow-still]

@AMollis your more recent comments are along a completely different line than the original bug report.

If there is a slowdown after running some amount of time, then that would be a great issue to file. Please include the usual config info and repro steps. There's additional guidance on contributing useful and actionable issues in the documentation.

It's tempting to take shortcuts in submitting issues, but I assure you that every little bit of clarity and organization helps. Part of this includes keeping issues focused, and not recycling them into related issues.

So again, I would encourage you to file an issue with as much detail as you can on a slowdown after about 20 minutes. Thanks!

[fast-slow-still]

Also, @AMollis , if the version info you gave above is accurate, then before putting together a bug report, I would suggest that you update your plugins. Your MROpenXR plugin is extremely out of date. The OpenXR team has been making great strides in performance and stability since that early version. Your Unity openxr plugin is also behind by at least a minor version.

If there is an issue with XRSDK slowing down after running a while, then it would be best for us to alert them to the issue so they can fix it.

And I have to reiterate, yes, I do frequently run on HL2 for longer than half an hour, but I have not seen this slowdown. So it would be great if, when you report this issue, you can provide enough context for someone to reproduce the problem without having access to your application. Thanks!