How could BodyNodeSlot's performance be improved?

[brecert]

I wasn't really sure whether to make an issue or discussion for this but a discussion seemed better since it's intended behavior and not really an issue outside of "BodyNodeSlot is laggy with how it's commonly used", and how to improve it may need discussion if it involves changing the current behavior of it. Please direct me towards creating an issue if this is incorrect.

The BodyNodeSlot node currently functions by going through every slot and component looking for a bone that matches the BodyNode. This has a worst case of searching every single slot + component on the user root looking for one that matches.

When paired with a continuously updating flux group it can eat away at performance innocuously because it does not seem like it should be that heavy. It can be hard to notice because one avatar may have a best case early exit while another may not even have a matching body node and will have worst case performance.

There have been two instances where I investigated performance in a world when trying to improve it and all of the fps loss was from a worst case BodyNodeSlot in an avatar with a lot of slots. Storing the result helped but it required knowledge about this non-obvious behavior first.

Recently I've started using https://github.com/esnya/ResoniteMetricsCounter, and what's immediately jumped out at me is how many instances of BodyNodeSlot are being used in continuous groups across random avatars/objects, leading to those flux groups often being towards the top of the chart.

VRIK and other heavy components/patterns are still (generally) heavier than a single BodyNodeSlot with a non worst case search, but it still adds up. I've also found BodyNodeSlot is usually paired with another one for chirality reasons, compounding the issue.

What this discussion is about is a question of how the performance of the node can be improved without requiring rewriting all previous flux that uses it, and how new flux can avoid those issues as long as performance remains poor.

Here's an example of one instance I found that was very simple and had poor performance.

[AwesomeTornado]

Esnya's metrics profiler mod is great, I love it and use it all the time. However, the mod does not profile the entire process of generating a frame, and cannot always give a fully accurate measurement as to how performant something is. I would be very curious as to how much fps you gain/lose when deleting and spawning the example you show. (saying this early on because there have been misconceptions about this in the past) Additionally, reproduction avatars/systems could help a lot if you have access to them.

Based off of the numbers shown on the profiler, your frame times could be improved by ~.4ms, which might equal a 1fps improvement. However, you do mention that this has been the cause of significant frame loss in the past, so I can't say conclusively how much of an issue this is. While it could be argued that it is the users job to store the result of this node, there may be a way to allow it to automatically cache and refresh its result, though I am not sure if this goes against the spirit of continuously changing flux nodes.

I might try to make a mod that automatically caches the result of this node and skips the search. I'll report back if I end up doing it, along with whether or not it helped performance significantly.

[AwesomeTornado]

Ok, so I did some testing with making a mod. It seems like this component can cause a drop of about 3-4 FPS. With the mod I created to cache the results, the drop is lowered to about 1 FPS. This mod is NOT intended for general use, as it is not currently able to detect when the cached result will need to be regenerated. I'll post more as I learn more. Just to throw out the possibility, there is the chance that a mod could be considered an acceptable solution to this problem, as the node is functioning as intended right now, but could be changed as per user preference with a mod.

https://github.com/AwesomeTornado/CacheBodyNodeSlot

[AwesomeTornado]

Ok, after some more testing and coding, it seems like the method that I am using for caching does consistently result in a ~4fps improvement. Below is a screenshot of one of my tests. On the top, there are the tests using my mod. On the bottom, there are the tests without my mod. On the left side, there is a single continuously updating bodyNodeSlot protoflux node searching for a nonexistent slot. On the right, this node has been disconnected.

My mod has been updated to automatically update its cached values when slots are added or removed and should be one possible solution to your original issue, but as always with community made content, be aware that there may be bugs and issues with my mod that are unrelated to anything Resonite is doing.

I think this provides a pretty good answer though. Continuously updating BodyNodeSlots do impact performance and can be heavy on the game. By adding caching to them, you can gain a couple extra FPS. While it is not my choice on whether or not this will be or even should be added to the game, you can always try it out through my mod. As for solutions that don't require a mod, I believe that the best solution is to cache the result yourself using variables.

https://github.com/AwesomeTornado/CacheBodyNodeSlot

[brecert]

I've been looking into how values can be cached with flux. If the flux happens to be part of an tool or avatar then you can detect when the active user changes and update the cached value which is often good enough.

For instances that are used outside of the UserRoot like the one I initially showed it I'm having trouble finding a consistent and reliable way to determine when the slot may change.

In both instances there enough avatars with dynamically equippable body nodes where I'm not sure how to check for slot changes like that in a trivial way.

[Zyzyl]

Setting aside the possibility of an under-the-hood technical improvement to this, I think this really comes down to user knowledge / education. It's been generally known for a long time that certain operations can be comparatively expensive (e.g. FindChildByName or SampleColor). If you find nodes like BodyNodeSlot which seem to have an unexpectedly large impact you could make a note on the Wiki, perhaps on the node's page and/or on https://wiki.resonite.com/Optimization_Guidelines, and try to spread the information around. It'll make it's way through the community eventually.

The point you make about manually caching values from nodes where possible is also good - I do this quite often. I guess some users may try to avoid that based on misunderstandings about the performance costs re: writes vs. drives?

Another point, if users are simply looking for slots or positions of common avatar parts (e.g. head, hands, feet) there are some nodes under Users > UserRoot which can provide those without needing to use BodyNodeSlot at all.

[brecert]

Encountered this again and had to explain why it's so laggy to a user, and still have not found a good way to cache it robustly if it's not parented under the user.

It feels very unintuitive that it has a worse case complexity like it does.
So far I've had to explain this issue to 10-15 people and many of them were wondering why it would have a complexity like that because of a thought process like "shouldn't body nodes be a fast dictionary lookup anyways" or similar.

My current thought and suggestion currently is to make BipedRig a UserRootComponent or at the very least a registered component so that the node can do a dictionary lookup of user's BipedRig components without needing to do the recursive search.

[Frooxius]

I haven't had time to look into this depth, but generally there's one problem with caching - when/how do you invalidate the cache?

While this speeds up the lookup of things, it risks altering the behavior of the node, especially when things change. For example a following sequence can occur:

1. Get body node - gets cached
2. Modify avatar/hierarchy etc. so the body node would end up changed
3. Get body node - returns cached value, but this is now wrong.

I'd have to poke into things to see if this would be easy or not, but it's one of the issues that I feel is often forgotten about - cache invalidation tends to be one of the biggest three issues in programming x3

With user-side caching, the caching itself can be structured to work with given user logic, but doing a general caching cannot make any assumptions.

[brecert]

My current thought and suggestion currently is to make BipedRig a UserRootComponent or at the very least a registered component so that the node can do a dictionary lookup of user's BipedRig components without needing to do the recursive search.

Is what I mentioned applicable? It's still "caching" (very loosely) the BipedRig so it becomes a search of a few dictionary lookups. The only case I'm aware of that wouldn't behave the same would be if the body node slot relies on the slot order of multiple separate BipedRigs changing dynamically.

[Frooxius]

It could possibly work by making them registered - in fact that's along the lines I'd go with this to improve how it behaves - make sure the body nodes explicitly register and unregister themselves.

I'll have to check the details of the node itself though to make sure that there's no other influences and things like that.