Hello, studio testing doesn’t use --!optimize 2 by default, Roblox games do. So I forced it to give me results as close as possible to in-game testing
Native, I left since I kept the headers the same, but yh not all are supposed to have it; they where mainly there for serialisation and compressions
Edit:
Thanks for the PR on the repo. I’ll check it out soon 
Not quite.
Compilers don’t always make the best choices. Hand-tuning still win when every cycle counts. General-purpose tools just can’t match that.
This is for a basic string
Roblox
Packet module
NetRay
Edit: I will add more as I continue testing
Correct, but since we cannot write our own bytecode, we must rely on the compiler to do as much as possible. Hand tuning always wins over general purpose tools for performance, that is my point
Okay that’s absolutely insane if accurate.
Are you sure there isn’t more being done by Packet. I mean it is literally worse than Roblox, that’s weird?
IIRC, Roblox already compresses packets for you before sending them. Your packet visualization plugin will not track that
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Packet = require(ReplicatedStorage:WaitForChild("Packet"))
return {
Testing = Packet("Testing",Packet.String)
}
This is the packet, I am not sure if I am doing something wrong but that’s all I did to it
Roblox serializes the data you pass into remotes into an internal binary format for transmission. This format is optimized for their network layer, but not compressed.
OK I just checked, Roblox uses zstd to compress buffers for you
Sure, but we can still do things which the compiler doesn’t account for.
I don’t think anybody would interpret your message as having that point.
But if that’s what you stand for, then we agree.
I cannot find a source for this at all
To my knowledge and search, zstd is used for
DataStore v2 / MemoryStore
HTTPService
Asset Streaming (e.g. Terrain)
It’s probably true that the packet visualization plugin won’t track numerous things.
The best way to check overall data usage and performance is to just check it in-game with the performance stats bar.
How is this system making sure that there is no data being lost/changed when compressing? Usually when there is a high compression rate the chance for problems with data loss are raising as far as I know.
If it’s used for all other types of networking in Roblox, it’s probably also used for remotes.
Yep, the packet visualizer does not show packet information after roblox does their internal processing
The Lempel–Ziv–Welch (LZW) algorithm is a lossless data compression algorithm,
It also fallsback to JSON if it can’t handle anything with a custom implementation for Roblox data types
By “it” do you mean the algorithm, NetRay or something else?
It seems to be the algorithm you’re referring to, but I can’t get it to make sense in this context, because LZW isn’t Roblox-based?
Sorry, I confused myself. The LZW module I wrote first changes the data using JSON + custom encoding to handle Roblox types, as JSON encoding can’t handle Roblox types via HTTP service. then the LZW compression algorithm compresses it.
What I was referring to as fallback was the serialisation; it will try fallback to JSON as a last resort if it cannot properly serialise the data into a buffer
I placed a short description at the top of each module (mostly)
Provides functions for compressing and decompressing complex Luau data
using LZW algorithm after converting the data to a JSON-compatible string format.
Handles various Roblox datatypes and nested tables. Includes detailed debugging.
It’d be awesome if you could do a quick benchmark with Roblox, Packet and NetRay.
Instead of using the packet visualization plugin, use the performance stats in-game.
Packet can’t seem to handle the entire string because it only gives me a partial string, so I am unsure if that value on received is entirely accurate since it’s missing data
Packet module:
Roblox:
NetRay:
The packet module only seems to give me 4% of the overall data when sent, so I am not sure if its values are correct
