3 ms·
If protobuf works for Google then it essentially works for 99.999% of every other company on the globe. I can't agree with this mindset. Another commenter her
by rkagerer 6y ago
If protobuf works for Google then it essentially works for 99.999% of every other company on the globe.
I can't agree with this mindset.
Another commenter here pointed out the Google implementation is 20x slower than others, and 1.6MB for this kind of task feels bloaty. Just because it meets Google's needs doesn't mean it's universally adequate.
- ikiris 6y agoWhy exactly does a megabyte matter, unless you're trying to run on a 90's watch or embedded?
- FpUser 6y agoMaybe because "20X slower"
- dweis 6y agoThese are simply tradeoffs. For example, one can make very fast protobuf parsers/serializers if you prioritize that over the ergonomics of the generated code.
- naniwaduni 6y agoWell, transmitting a megabyte also takes a full second at 8 Mbps.
- RhodesianHunter 6y agoNobody's transmitting this, it's the size of the library doing the proto serialization/deser
- ma2rten 6y agoI did a search on this page and I didn't find the comment you are referencing. It seems very unlikely to me that google's implementation is 20x slower.
- rkagerer 6y agoSee tijsvd's comment about 1 microsecond vs. 50 nanoseconds. (Perhaps I should have caveated that with "in some scenarios")
- asdfasgasdgasdg 6y agoWhich implementation of protobuf is 20x faster than Google's?
- dguaraglia 6y agoI think the general point is 'if it works for Google, you should feel relatively safe adopting it for your own use'. It doesn't mean it'll fit every single usecase. If what you need is something that is super efficient over the wire - or any other such requirement not filled by Protobuf - then maybe look for a different protocol altogether. Or design your own! But for the rest of us - the '99.999%' - the trade-offs are well understood and we'd rather go for the tool we know than reinvent the wheel or use a less maintained tool.