Hacker News Reader

Comment by rkagerer | Hacker News Reader

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.

View on HN

I 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.

See tijsvd's comment about 1 microsecond vs. 50 nanoseconds. (Perhaps I should have caveated that with "in some scenarios")

I 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.

Which implementation of protobuf is 20x faster than Google's?

Why exactly does a megabyte matter, unless you're trying to run on a 90's watch or embedded?

Maybe because "20X slower"

These are simply tradeoffs. For example, one can make very fast protobuf parsers/serializers if you prioritize that over the ergonomics of the generated code.

Well, transmitting a megabyte also takes a full second at 8 Mbps.

Nobody's transmitting this, it's the size of the library doing the proto serialization/deser

Reply on news.ycombinator.com