Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Use Protobuf for Telemetry

richardstartin.github.io

Post reply on HN
Print view View original

111–120 of 195 posts

Re: Don't Use Protobuf for Telemetry

#111

Post by Scaevolus »

tijsvd wrote: post #31

I have written an in-house implementation of protobuf for C++ (sorry can't share) and studied the wire format extensively. Google's implementations, at least C++ and Java, are a bunch of bloated crap (or maybe they're very good, but for a use case that I haven't yet encountered). Don't shoot down the format because of a specific implementation, find or write a better one and enjoy the fact that every language has at…

Here's a minimal Python protobuf parser that can extract basic information in about 50 LOC.

https://github.com/kubernetes/test-infra/blob/master/guberna...

Re: Don't Use Protobuf for Telemetry

#112

Post by bigiain »

sofixa wrote: post #94
sebastos wrote: post #84

Earlier quoted context omitted.

This over-assuming-of-shared-context is one of my pet peeves on this site. Based on the average post you see on Hackernews, it's a virtual certainty he means "snooping on users of a program". I can't explain why, but it just bothers me that this would be considered so obvious as to escape mention. "Telemetry" means something, and it meant something to aerospace engineers for a long time before somebody at google star…

> Based on the average post you see on Hackernews, it's a virtual certainty he means "snooping on users of a program". I can't explain why, but it just bothers me that this would be considered so obvious as to escape mention. "Telemetry" means something, and it meant something to aerospace engineers for a long time before somebody at google started using it to refer to something incredibly narrow. Did you even read t…

I read the whole post, and had to do a mid-post brain state reshuffle to get out of my assumed “pump in the field” context to his ”snooping on users” context.

This for me, is because I’m playing with an ESP32 based project which uses protobufs, and I clocked into it from that mind set.

The intended use of “telemetry” was not obvious for me, until some way until reading the piece. Even the first mention of Datadog didn’t raise any suspicions to me, it was the use of Java that first had me wondering, then down around the 6th para the lightbulb went off when he said “a diagnostic agent which tells you what your application is doing” that I stopped and re oriented my brain.

Re: Don't Use Protobuf for Telemetry

#113

Post by bigiain »

sebastos wrote: post #100
sofixa wrote: post #94

Earlier quoted context omitted.

> Based on the average post you see on Hackernews, it's a virtual certainty he means "snooping on users of a program". I can't explain why, but it just bothers me that this would be considered so obvious as to escape mention. "Telemetry" means something, and it meant something to aerospace engineers for a long time before somebody at google started using it to refer to something incredibly narrow. Did you even read t…

Well, I started to read the article, thinking that it might refer to sending, you know, telemetry. The hackernews link was titled like this: >Don't Use Protobuf for Telemetry so I thought I had a shot of reading something relevant to me. So I opened up the article: >Protobuf needs no introduction, but this post argues that you shouldn’t use it for telemetry. The basic premise of this post is that a good telemetry lib…

To be fair, if you don’t want to read grand proclamations about opinions which make zero sense except for people in roles tightly related to surveillance capitalism, perhaps this isn’t the site for you. (Us...)

Re: Don't Use Protobuf for Telemetry

#114

Post by bigiain »

kentonv wrote: post #88
kentonv wrote: post #76

Earlier quoted context omitted.

> It seems clear enough that protobufs were optimized in a scale that involved a lot of time/cost-sensitive reads and far fewer time/cost-sensitive writes. Nah, you're assuming too much. Protobuf was thrown together in a fairly ad hoc way by a couple (brilliant!) engineers (Jeff and Sanjay) to help make the Google search index protocol easier to maintain. The specific design decisions in Protobuf were not carefully t…

> The specific design decisions in Protobuf were not carefully tested or weighed against other possibilities. And just to be clear, I don't think this is bad. On the contrary, I think Protobuf won because it did a wide variety of things "pretty well" while moving quickly and solving real problems. This is how the best technologies are usually made, not by academically trying to perfect everything, but by banging out…

“Rough consensus and running code.” Works pretty well most of the time.

Re: Don't Use Protobuf for Telemetry

#115

Post by tele_ski »

janders wrote: post #8

I want to be a fan of Apache Avro ( https://avro.apache.org/ ) so much for situations such as this. And while I like Avro as a standard, most of the implementations I have found (specifically in C/C++) are... lacking. I feel Avro would be a great fit for something like this close to zero overhead (assuming a pre-shared schema) but there is little to no support for pre-shared schema and the RPC part of the standard is…

I think AVRO is fairly well designed overall, but JSON schemas? If you need deeply nested objects just look away, it becomes unintelligible when trying to understand the schema with any real nesting. The company I was at used it fairly well as long as you keep things 1 or 2 levels nested at most, but we had a legacy schema that was 5 or 6 levels deep at some points and it was just a disaster. My anecdote anyways.

Re: Don't Use Protobuf for Telemetry

#116

Post by kentonv »

vvanders wrote: post #108
kentonv wrote: post #102

Earlier quoted context omitted.

Unless you are targeting a constrained embedded system, this kind of anti-memory-allocation thinking is counter-productive. Avoiding memory allocation significantly increases the complexity of an API -- or worse, leads to shortcuts like using (thread-unsafe) globals or (overrun-prone) fixed buffers. In C, dealing with memory allocation is such a pain that C programmers still tend to avoid it. But C++, especially post…

Constrained embedded systems cover a broad range of things up to and including your phone. There's few things I hate to see more than a flat profile from memory allocation or cache misses. The good news is that flatbuffers[1] is a reasonable replacement for most of my use cases. In particular being able to mmap() them directly is a wonderful thing that you can't do with protobufs in addition to being very allocation…

> Constrained embedded systems cover a broad range of things up to and including your phone.

No, modern phones are certainly not constrained in the way I meant, and I don't think you could call them "embedded" either. The common programming languages used on phones are very memory-allocation-friendly.

> There's few things I hate to see more than a flat profile from memory allocation or cache misses.

I think you may be arguing a different point, or a different level of extremity of the point. Reducing memory allocation to optimize performance is a fine thing that everyone does. The person I was replying to, though, seemed to be asserting that libraries should completely avoid allocating memory for themselves.

> The good news is that flatbuffers[1] is a reasonable replacement for most of my use cases. In particular being able to mmap() them directly is a wonderful thing that you can't do with protobufs in addition to being very allocation sparse.

Yeah... I'm the author of Cap'n Proto, which has the same property, and predates Flatbuffers.

Re: Don't Use Protobuf for Telemetry

#117

Post by mLuby »

sebastos wrote: post #100
sofixa wrote: post #94

Earlier quoted context omitted.

> Based on the average post you see on Hackernews, it's a virtual certainty he means "snooping on users of a program". I can't explain why, but it just bothers me that this would be considered so obvious as to escape mention. "Telemetry" means something, and it meant something to aerospace engineers for a long time before somebody at google started using it to refer to something incredibly narrow. Did you even read t…

Well, I started to read the article, thinking that it might refer to sending, you know, telemetry. The hackernews link was titled like this: >Don't Use Protobuf for Telemetry so I thought I had a shot of reading something relevant to me. So I opened up the article: >Protobuf needs no introduction, but this post argues that you shouldn’t use it for telemetry. The basic premise of this post is that a good telemetry lib…

The practice of naming software or start-ups after real, useful terms from other industries is super annoying to me.

And it's especially unconscionable for web devs, who should be more wary than most about global namespace collision (looking at you, browser window). At least have the decency to change the word slightly.

Re: Don't Use Protobuf for Telemetry

#118

Post by ma2rten »

rkagerer wrote: post #99
saberience wrote: post #97

Earlier quoted context omitted.

You don't work for Blizzard do you? When I worked there engineers (not my team thankfully) designed their own alternative to protobuf to try and save more bytes over the wire, which in my opinion was a really poor decision. Rather than get on with actually adding value, they ended up pushing back multiple other teams deadlines while adding almost no value. It was a classic "not built here" mentality and doing enginee…

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.

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.

Re: Don't Use Protobuf for Telemetry

#119

Post by contingencies »

Optimization: Prototype before polishing. Get it working before you optimize it. - Eric S. Raymond, The Art of Unix Programming (2003)

The First Rule of Program Optimization: Don't do it. - Michael Jackson

The Second Rule of Program Optimization (for experts only): Don't do it yet. - Michael Jackson

Spell create with an 'e'. - Ken Thompson (referring to design regrets on the UNIX creat(2) system call and the fallacy of premature optimization)

The No Free Lunch theorem: Any two optimization algorithms are equivalent when their performance is averaged across all possible problems (if an algorithm performs well on a certain class of problems then it necessarily pays for that with degraded performance on the set of all remaining problems).

... quotes via https://github.com/globalcitizen/taoup

FWIW at my company we do embedded robotics, use ridiculously underpowered processors with very limited capabilities, and still prefer use HTTP as it is well understood, has good tooling and is easy for everyone to deal with, which reduces real world business costs vs. custom wire-level formats. I'd gently suggest that unless you have a really particular use case (real time stock market feeds where latency is paramount, very expensive or constrained link layer) it makes little sense to worry about this sort of optimization.

Re: Don't Use Protobuf for Telemetry

#120

Post by andrekandre »

jasonzemos wrote: post #107
haberman wrote: post #80

Earlier quoted context omitted.

> make apologies from authority (after all, Google can't do anything wrong, right?) That's not my position at all. In my other comment ( https://news.ycombinator.com/item?id=25586447 ) I explain how I've spent 10 years trying to improve on protobuf C++ precisely because I agree that some of these limitations are unnecessary. > No zero-copy for networking? Forced internal heap allocations with only this arena feature…

> I suppose it depends what you are comparing it to. Almost every JSON library has the same limitations you mentioned, and yet many people find JSON useful for network applications. JSON is a human-readable format which is hugely advantageous to develop and operate in many settings. Protobufs doesn't have that advantage. Yet we're paying all of the same costs to structure the data with both. That's enough to posit JS…

> Forcing std::string as a container for core components of a networking API (specifically for an accessor) is an exemplary demonstration of a lack of seriousness in a library.

im not super experienced with c++, so please forgive the maybe obvious question, but why is that?

(im guessing it has to do with allowing control over where allocations come from?)

Post reply on HN