quick-protobuf
msgpack
quick-protobuf | msgpack | |
---|---|---|
3 | 5 | |
433 | 6,839 | |
- | 1.5% | |
6.3 | 0.0 | |
3 months ago | 3 months ago | |
Rust | ||
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
quick-protobuf
-
Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance
[quick-protobuf]: https://github.com/tafia/quick-protobuf
-
Add extra stuff to a “standard” encoding? Sure, why not
I actually went through all projects listed in [1] because I remember this very quirk. It turns out that there are many such libraries that have two variants of encode/decode functions, where the second variant prepends a varint length. In my brief inspection there do exist a few libraries with only the second variant (e.g. Rust quick-protobuf), which is legitimately problematic [2].
But if the project in question was indeed protobuf.js (see loeg's comments), it clearly distinguishes encode/decode vs. encodeDelimited/decodeDelimited. So I believe the project should not be blamed, and the better question would be why so many people chose to add this exact helper. Well, because Google itself also had the same helper [3]! So at this point protobuf should just standardize this simple framing format (with an explicitly different name though), instead of claiming that protobuf has no obligation to define one.
[1] https://github.com/protocolbuffers/protobuf/blob/main/docs/t...
[2] https://github.com/tafia/quick-protobuf/issues/130
[3] https://protobuf.dev/reference/java/api-docs/com/google/prot...
[4] https://github.com/protocolbuffers/protobuf/blob/main/src/go...
msgpack
- SQLite needs testers for the new binary JSON format
-
Salt Exporter: the story behind the tool
I also read that Salt was using MessagePack to format their messages. MessagePack is a format like JSON, but more compact.
- Add extra stuff to a “standard” encoding? Sure, why not
- MessagePack: It's like JSON, but fast and small
-
mus-go - the fastest Golang serializer today
Sorry, but I don't think it looks like MessagePack. I wonder why you think so? MUS format does not contain a data types, unlike MessagePack. So, for example, the uint8 type in MessagePack can be encoded with two bytes (from the MessagePack specification): uint 8 stores a 8-bit unsigned integer +--------+--------+ | 0xcc |ZZZZZZZZ| +--------+--------+ The same data type in MUS format is encoded with just one byte. This fact alone is quite a significant difference.
What are some alternatives?
riegeli - Riegeli/records is a file format for storing a sequence of string records, typically serialized protocol buffers.
protobuf-conformance - A repository running the Protobuf conformance tests against various libraries
protobuf - Protocol Buffers for JavaScript (& TypeScript).
mqtt-exporter - Simple generic MQTT Prometheus exporter for IoT working out of the box
nix-init - Generate Nix packages from URLs with hash prefetching, dependency inference, license detection, and more [maintainer=@figsoda]
imstr - Immutable strings, in Rust.
zoa - serialized structured data and it's textual representation
flapigen-rs - Tool for connecting programs or libraries written in Rust with other languages
SaltStack - Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
Protobuf - Protocol Buffers - Google's data interchange format
go_serialization_benchmarks - Benchmarks of Go serialization methods