Optimizations for parsing and receiving OSC messages from recv.

[regzo2]

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]

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.

[benaclejames]

I'm all for improving on the osc stuff yea! I think some work defo needs to be done in fti but I'd love to hear what you think in terms of what needs improving.

[benaclejames]

Just curious as to why this was changed to 64

[regzo2]

I found that received messages never exceeded 64 bytes from VRChat but OSC never standardized a message size limit so having the buffer be as big as possible would be safer. This would also be a VRChat OSC specific optimization too.