Since we still don't have explicit rule/method to add NextFrameIfTimedOut, this change may seem random.
But we've conducted some benchmarks and profiled them before add these await-s. These changes ease CPU spikes.
This is a breaking change since it introduces new interface method to IAwaitCaller.
----
NextFrameIfTimedOut() is added to IAwaitCaller. The following inheritors also introduce the method.
- ImmediateCaller.NextFrameIfTimedOut() just invokes NextFrame().
- RuntimeOnlyAwaitCaller.NextFrameIfTimedOut() invokes NextFrame() if timed out. Otherwise, do nothing.
- RuntimeOnlyNoThreadAwaitCaller.NextFrameIfTimedOut() works same as RuntimeOnlyAwaitCaller.
Constructor of RuntimeOnlyAwaitCaller and RuntimeOnlyNoThreadAwaitCaller
now take argument of timeout in seconds. The default value is 1/1000 (1 milliseconds).
See also:
https://github.com/vrm-c/UniVRM/pull/1781#pullrequestreview-1100131840
This change adds (pseudo) method RuntimeOnlyAwaitCaller.NextFrameIfTimedOut()
which invokes NextFrame() if given time is elapsed. Otherwise, it does nothing.
We'll be able to utilize this (pseudo) method to ease possible cause of spikes.
For example:
----
public class VRMImporterContext : ImporterContext {
protected override async Task OnLoadHierarchy(IAwaitCaller awaitCaller, ...) {
...
var blendShapeList = VRM.blendShapeMaster.blendShapeGroups;
if (blendShapeList != null && blendShapeList.Count > 0) {
foreach (var x in blendShapeList) {
await awaitCaller.NextFrameIfTimeout();
BlendShapeAvatar.Clips.Add(await LoadBlendShapeBind(awaitCaller, x, transformMeshTable));
}
}
...
}
}
----
Note that this change doesn't add NextFrameIfTimeout() to IAwaitCaller to avoid
breaking change. This limitation introduces extra (maybe unnecessarily) complexity.
This change optimizes the following points:
(1) Replace linear search for "cashedHumanTraitBoneName" with Dictionary.
(2) Avoid GC alloc in the inner loop.
(2a) Do b.ToString() at the outside of the loop.
(2b) Do x.Replace(" ", "") at once in the static constructor of BoneLimit.
