Assorted perf improvements in hot code paths#10601
Conversation
…ir interaction state
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
… patterns Currently, there are two InputDevices: one with interaction data and one with hand joint data. Going forward, there may only be one 👀
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
| using (UpdateCurrentIndexPosePerfMarker.Auto()) | ||
| { | ||
| if (unityJointPoses.TryGetValue(TrackedHandJoint.IndexTip, out currentIndexPose)) | ||
| if (unityJointPoses != null) |
There was a problem hiding this comment.
Is it the case that if we can't get one joint, we can't get any of them? I think these cases were originally supposed to just check if specific joints were unavailable, while this change checks if any were reported at all.
There was a problem hiding this comment.
That's true...this does add an "all or nothing" assumption to the internals.
I have another approach around defining a new IDictionary type that's backed by an array, and then maybe we return pose != default(MixedRealityPose) or something. I can go down that path quickly and see the perf comparisons.
There was a problem hiding this comment.
This is the last thing that caught my eye in this PR. I think if we can avoid doing the all or nothing that'd be preferrable, though I'm willing to let the behavior fall through here if it's a small edge case and we get lots of perf improvement
| public void UpdateVelocity() | ||
| { | ||
| if (unityJointPoses.TryGetValue(TrackedHandJoint.Palm, out var currentPalmPose)) | ||
| if (unityJointPoses != null) |
There was a problem hiding this comment.
+1 on the joint question.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
david-c-kline
left a comment
There was a problem hiding this comment.
Good changes! Just a few nitpicks / readability comments
| get | ||
| { | ||
| if (!unityJointPoses.TryGetValue(TrackedHandJoint.Palm, out var palmPose)) return false; | ||
| if (unityJointPoses == null) return false; |
There was a problem hiding this comment.
nit: can you add { } around the return statement?
| unityJointPoses = jointPoses; | ||
| CoreServices.InputSystem?.RaiseHandJointsUpdated(InputSource, Handedness, unityJointPoses); | ||
|
|
||
| if (unityJointPoses == null) return; |
| case HandJoint.LittleTip: return TrackedHandJoint.PinkyTip; | ||
|
|
||
| default: return TrackedHandJoint.None; | ||
| case HandJoint.Palm: return (int)TrackedHandJoint.Palm; |
There was a problem hiding this comment.
maybe consider using a variable here and casting in a separate return statement? not critical, but might be a little easier to read w/o every line having a cast
| case HandFinger.Ring: return TrackedHandJoint.RingMetacarpal + index; | ||
| case HandFinger.Pinky: return TrackedHandJoint.PinkyMetacarpal + index; | ||
| default: return TrackedHandJoint.None; | ||
| case HandFinger.Thumb: return (index == 0) ? (int)TrackedHandJoint.Wrist : (int)TrackedHandJoint.ThumbMetacarpalJoint + index - 1; |
| case HandFinger.Ring: return TrackedHandJoint.RingMetacarpal + index; | ||
| case HandFinger.Pinky: return TrackedHandJoint.PinkyMetacarpal + index; | ||
| default: return TrackedHandJoint.None; | ||
| case HandFinger.Thumb: return (index == 0) ? (int)TrackedHandJoint.Wrist : (int)TrackedHandJoint.ThumbMetacarpalJoint + index - 1; |
| { | ||
| using (OnPreSceneQueryPerfMarker.Auto()) | ||
| { | ||
| if (!IsInteractionEnabled) return; |
| { | ||
| using (OnPreSceneQueryPerfMarker.Auto()) | ||
| { | ||
| if (!IsInteractionEnabled) return; |
| { | ||
| using (OnPreSceneQueryPerfMarker.Auto()) | ||
| { | ||
| if (!IsInteractionEnabled) return; |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Overview
These traces are using in-editor remoting.
Before:

After:

forloop end conditions, so we don't continually query properties orLengthorCountvaluesCoreServicescalls in hot loopsOnPreSceneQueryif they aren't enabled and their enabled state doesn't depend on work inOnPreSceneQuery