Skip to content

Conversation

regzo2
Copy link
Collaborator

@regzo2 regzo2 commented Feb 10, 2025

Simple as it sounds. There are a few more optimizations that I want to explore but these already give a huge performance bump!

Some points:

  • Without going into unsafe, manually marshalling the parameters and avoiding reflection gave a nice boost
  • Thread spooling on the parsing had a lot of overhead, so we just don't do it.
  • Is it possible to configure VRChat's OSC sender socket to omit specific /avatar/parameters/* from being sent over? We don't really need to track face tracking parameters outside of the toggles. This would drastically avoid redundant receives and parsing of OSC messages. Fun fact but nearly 90% of the use of RecvService is parsing redundant messages from VRChat!
  • The way the datagrams are sent to the socket, it isn't really possible to parse it into a big packet and parse as a bundle from one Receive call.

I guess it's just typical VRChat OSC jank 😅.

@regzo2
Copy link
Collaborator Author

regzo2 commented Feb 16, 2025

I have an idea on how to reduce as much overhead on OSC parameter parsing as possible:

  • We can evaluate a message's OSC address only, store that in a partial alongside the rest of the bytes.
    • Upon partial evaluation, we can pass the partials onto the switch and then evaluate the rest of the message after a case.
    • This would require additional features in fti to facilitate this (would not be that much work but still), which I could also make PRs to.

Not sure how much this would help but it would drastically reduce the amount of processing that needs to be done on the redundant parameters, and avoiding extra marshalling on OscValue and type parsing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant