I serialize only data that don't occur a lot like broadcasting started or match ended. The arena messages are stored and sent together every 0.1 seconds as one sending (unserialized), if there is something in the queue.
I could index the most used spellids, but this wouldn't reduce the overall data size that much. timestamps are excluded in broadcasts.
when you choose to broadcast, the match information gets saved to the match object (for standard local recording) and additionally sent to the addon channel. therefore everyone who listens to the specific sender, will display the received messages immediately on their player.
Oh hi, you're the author.
If you really wanted to be fancy, you could setup some additional complexity where when you enter an arena match all the people using the addon do negotiations so you can distribute the comms. For example, on 3vs3, if 2 of the 3 players have the addon, you could have each player send their own comms, and do additional checks to figure out who gets to send the 3rd players data.
The main downside to a system like this, besides the complexity is the fact that disconnects can mess it up, and renegotiation once you figure out someone disconnected is a bit awkward. Since, if someone disconnects you probably lost or the match was already decided, it's not a huge issue. If you want something like that, I can give you more details on how you would implement it.
Streaming to multiple people who aren't in the same guild/group/whatever, would require sending data into a custom chat channel. You can't really get around that if you want live streaming, a relay setup is going to be far more of a pain than just letting people set a custom data channel and syncing them all to join it.
I would have to look into the data scheme more to give something more specialized but, sending messages every 0.1 seconds is overkill. Given you already have to factor in latency between the players you're already looking at least 100ms before other people see the data sent. Grouping it every 0.5-1 second would give you roughly the same results.
Some code notes:
Tables work well for cleaning up code where you have multiple cases, for example your CHAT_MSG_BG_SYSTEM_NEUTRAL function can be turned into: https://gist.github....f72dd066ae82f4a
Memory is not a profiling metric. The memory count you're referencing in the description, as are 99% of people talking about is static memory, what you want to watch out for is garbage memory which is when you create a lot of tables and quickly dereference them. Even then, garbage memory isn't killer, unless you are doing something very wrong.
You don't need to define your own string split, WoW already has one, string.split. It's also more efficient since you won't be creating a table every time you call it.
An example of where you can avoid creating garbage memory is your comm code. It's unnecessary to serialize everything, you can use a string.split to get the arguments out of most comm code. Serialization is more useful for sending complex tables, but simple things like a version check should just be done with a string that is parsed out.
Variablessss, don't use single letter names. M and T are bad variable names for example.
There's a few more, but need to go back to work, I'll look tomorrow.