Does Replica support sera for serializations?
There’s also Sera.LossyCFrame that costs 28 bytes and has perfect coordinate and 0.0005’ish degree precision for rotations.
I have a feeling your implementation might lead to rotation imprecisions up to a degree or maybe even more. At that point you could just convert to euler angles and risk gimbal lock at 24 bytes.
3 Likes
Good point, I’ll add an option to use the rotation matrix or axis angle
1 Like
I wrote my SerDes library completely from my own 15 years of Lua expertise in what I understand as “fast code” so I haven’t been doing much comparison to other libraries. For fun I’ve taken your module for comparison. Here are the results:
First of all it’s a bit of a apples to oranges comparison to compare schematized and non schematized SerDes libraries since they have different goals in mind, but we can try to see just how different they can be if they’re trying to do the same thing:
By defining strict types and anticipating value order with a schema the serialized result becomes pretty compact. Your library defaulting to non f64 numbers destroyed the UserId field - Roblox floats support integer precision and UserId’s have surpassed 2 ^ 32 which means the only native datatype in Roblox to hold UserId’s is f64 aka the generic Lua number type. You can take that into consideration whether a non-schema SerDes should default to f64 numbers or something else.
As for the speed:
There’s over a 30x speed difference when serializing this type of table. I’ve created Sera for a project where I will need tons of serialization at runtime for replicating game state so I’m planning to push Roblox to it’s limits lol.
2 Likes
Dang, this is definitely one hell of a wake up call… that speed difference is really big, I assume because of more loops in mine. Though, for the UserId I would store them as strings instead of numbers.
Also, you can specify a number size type (idk what to call them) by doing Converter.Serialize(…, {numbersAs = “f32”}) (for example), though this does do it for all numbers and would benefit from a schema system (like yours), I guess it really is comparing apples to oranges.
Also also, I would still like you to implement null terminators to completely eliminate the size limitation, I honestly am considering switching to this from my own module if you do implement it 
1 Like
I want to avoid operations where my module would have to look for a null terminator - my goal with Sera is to do as few Lua operations as possible and let the native code behind Lua do the most heavy lifting. Using Sera.String32 would give you limitless string size while having negligible serialized size impact.
1 Like
Well, alright. You learn something new every day…
Also, 15 years?? That’s longer than I’ve been alive! 
Holy?? It is that fast? I was planning to use Squash, but I am planning to switch now, thank you for this godly resource
1 Like
Quite fast but caching and/or splitting the workload speeds it up hell a lot more. I use mine for exporting or importing large game assets even so still takes a bit of time
1 Like
Also, for a frame of reference on how much data/bandwidth this can save, I checked the size of data for the serialized and unserialized versions of this data:
and the results were:
Unserialized (roblox default): 83 bytes
Serialized: 27 bytes !!
If you want to know how I saw how much data they took up, check this post: Introducing UnreliableRemoteEvents - #110 by Luaction
2 Likes
I was doing a few tests benchmarking Sera against Squash - Although I don’t feel like my tests were super high quality I do believe Sera would have to be up to x1.7 faster or at worst just as fast as Squash. Schematized SerDes is easier to write than manually filling the buffer with Squash. I also think Squash might’ve been written better in some regards (I expected it to run faster than Sera), but I’m personally only interested in schematized SerDes.
1 Like
Benchmarks are meant to compare actual processing time of pieces of code - putting processing in new coroutines or threads during the benchmark beats the purpose of a benchmark.
Putting code into coroutines can make throttling easier, but it doesn’t prevent overloading the processor since normally Lua runs on a single processor core and simply resumes a coroutine immediately after a previous one yields.
Its not threads what I mean is the data is split into blocks to be processed similar to QUIC protocol
1 Like
I use the IEEE 754 NaN value encoding method to serialize custom binary data directly within the fraction bits of a NaN value. This allows me to store small pieces of binary information in a compact floating-point format, which I like since it is ideal for embedding metadata, flags, or other small data that doesn’t need a full object structure. I’ve been focusing on making this as fast as possible, so I also use buffers to handle raw binary data, which lets me manipulate the bytes without the annoying overhead directly.
Pretty good method since it lets me serialize data efficiently, using buffers for fast reading and writing of the manipulated NaN values. And by avoiding the more complex serialization formats, I can quickly encode and decode binary data stored in the NaN’s fraction field.
The IEEE 754 standard, which is a method for floating point numbers in binary, is just naturally faster than more complicated serialization methods tbh. It breaks the number into three parts the sign bit, the exponent, and the fraction. This was made to be optimized for the hardware level, particularly when using hardware supported operations for floating point values but thats beyond Roblox.
Can you share whatever personal module you used in this benchmark?
1 Like
Not really, it uses other custom modules for buffers and a few other things, but this is the general idea:
2 Likes
Can Sera not pass in serialised data via a remote and deserialise it on the other end?
For example fire to the server and passing in the serialisation, then deserialising it on the server and vice versa;
I tried doing it but i’d get an error attempt to call a nil value even when i passed in the schema as well; is their any way to achieve cross communication when it comes serialised and deserilsation?
Probably the best way to make sure that both contexts get the same schema is to use a ModuleScript containing the schema, that way it’ll be replicated for both server and client.
As long as the schema is the same, both contexts will be able to write to and read the data
The reason why you can’t pass along the schema along with the remote event is because you can’t send functions over remote events
1 Like
I havent touched sera in a while; i tried what u said by placing a module in a replicated container; doesnt work as intended; my main point is whether i can serialise what i pass via a remote and deserialise it on the other end. if i cannot do that doesnt that defeat the purpose of what sera is?
I mean if it didn’t work as intended you probably did something wrong; this is basically how every single buffer serde/ networking library that uses schema does it (including my own, BufferConverter2)
Can you show how you’re storing the schemas?