I don’t really like how BufferEncoder uses null terminators though, using a length byte is a few bytes of overhead for more performance and also less limitations (you cant store numbers like 0 with null terminators without bit magic)
It doesn’t use null terminators though?
Except at the end of the buffer to indicate end of content, though this is redundant since the buffer length can be used instead.
Ahh my bad, mustve misread the source, yeah idkw hy you dont jsut use the buffer length
Also, I wanted to point something out about the CFrame serde, heres a test:
As you can see the precision is pretty good
But here is what you do for serde vs mine:
Idk if it works good it works good, but this is alot of lines for what can be achieved in a few… it’d be good for both users wanting to understand how it works and maintainability to not have things too complicated to follow
I originally did it that way to ensure that buffer content is okay, since if it doesn’t end with null then there’s something wrong with the encoding or decoding process
It stuck since then, but it’s not a big deal since its only one byte which would be much much less than the rest of the data
1 Like
Yeah it’s fine lol //30charlimit//
Cool I’ll take a look at it, thanks!
1 Like
How different is BufferConverter2 from ByteNet? Is BufferConverter2 better by any chance in terms of performance?
ByteNet is a networking library, bufferconverter2 is just for converting stuff into buffers in general :V
Also, currently I’m using a rewrite of this module, I don’t really recommend using the old one with the huge Data module cuz indeed it has become so big the performance is now subpar
2 Likes
Something interesting to note is that human readable formats, while simpler in theory, require parsing of text. They have the obvious disadvantage of taking up more space, but they also take more time to encode and decode compared to a binary formats, due to the additional amount of parsing required
1 Like