also discuss a real world use case where TinyBits is used to encode and transmit instrumentation data from a Ruby app. And I compare it to JSON and Msgpack

Beating them both by varying degrees in all tested metrics, payload size, process memory & performance overhead

github.com/oldmoe/tinyb...

I explain more about the new features and its benefits on my blog

t.co/FOJszyddCn

New gems and updates from @oldmoe.bsky.social @Sergio Bayona @joshuay03.bsky.social @bihi.bsky.social @simonjuk.bsky.social @bradgessler.com @st0012.dev @batsov.net @avohq.io and more

This also opens the door for some creative transformations, you can for example have a dict with enum values [glücklich, traurig, gleichgültig] on one side and [happy, sad, indifferent] on the other

Yes of course, you need to have the exact same dictionaries (in the exact same order) on both sides of the wire. Similar to a dictionary used with zstd or lz4. Keeping those in sync is on the user

Thanks for the catch, I pasted the wrong data, fixed now

This is basically protocol buffers (and other schema based encoders) territory, but while being 10X simple

Read more here:
GitHub.com/oldmoe/tinybits-rb/ADVANCED.md

I built this to communicate data between services, much like you would use JSON or MessagePack, just faster and smaller, specifically for the types of payloads I deal with

For a data set of 11 different documents, the TinyBits Ruby gem was faster that all other schemaless encoders tested (Oj, JSON, Msgpack & CBOR) for encoding and decoding, all while producing much smaller serialized sizes.

Unlike other binary formats, it was as compressible as text formats like JSON

I will share all the data samples soon in a repo. I believe the issue is rendering numbers as text, specially doubles with larger decimal values. Rendering these will always be more expensive than just writing the 8 bytes that make up the 64bit double for binary foramts