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

191–195 of 195 posts

Re: Don't Use Protobuf for Telemetry

#191

Post by vvanders »

cbsmith wrote: post #167
vvanders wrote: post #145

Earlier quoted context omitted.

> The common programming languages used on phones are very memory-allocation-friendly. I would hardly classify Dalvik or ART as "allocation friendly", they don't perform escape analysis and if you do it constantly you'll be in a world of constant hard GC pauses. Multiple times over the years I've had to build free-lists in Java to avoid this specific problem. Same for C++ if you use one of the built-in generic memory…

> I would hardly classify Dalvik or ART as "allocation friendly", they don't perform escape analysis and if you do it constantly you'll be in a world of constant hard GC pauses. Multiple times over the years I've had to build free-lists in Java to avoid this specific problem. I don't know what you're doing, but I've generally found free-lists to be a net performance negative in Java libraries. Time and again, I've be…

Dalvik and ART have different behaviors than traditional Java VMs. Dalvik is aimed at low memory devices, ART trades some memory for speed but still is significantly different(i.e. it doesn't do escape analysis). As always benchmarking on hardware is the way to confirm this but I've had numerous cases where free lists or pre-allocated arrays has gained 10-30x performance improvements.

Flatbuffers in particular excels here since once you have the ByteBuffer in memory you can immediately start accessing data without needing to do any extensive parsing.

Even the official Android docs are very explicit[1] on the allocation point. Allocations are not cheap and even with generational collection you still will blow the 16.6ms frame window for 60 FPS if any of your operations allocate excessively.

[1] https://developer.android.com/training/custom-views/optimizi...

Re: Don't Use Protobuf for Telemetry

#192

Post by rstartin »

bastawhiz wrote: post #109

Ignoring the bits about Java specifically, one thing that jumps out at me (while reading through the comments) is the distinction between use cases. It seems that the wire format puts some extra burden on the encoding side, but has the benefit of making decoding nice. In a situation where you're using protobufs internally, you're both encoding and decoding the messages. CPU hours aren't fungible, but you're paying a…

That's exactly the message I intended to get across.

Re: Don't Use Protobuf for Telemetry

#194

Post by tptacek »

JoachimSchipper wrote: post #27

Protobuf's variable-length lengths are indeed annoying, but can't you encode back-to-front as in ASN.1? That lets you write your lengths just after encoding the value, which should work (but may leave your data in e.g. bytes 20+ of a buffer; depending on interfaces, you may need to do one final copy to move the data to the start of the buffer.) (ASN.1 and protobuf are both tag-length-value formats with variable-lengt…

Hey, all I did was notice that Microsoft did that for X.509. h/t to Microsoft's cert parsing code team. :)

Re: Don't Use Protobuf for Telemetry

#195

Post by cbsmith »

vvanders wrote: post #191
cbsmith wrote: post #167

Earlier quoted context omitted.

> I would hardly classify Dalvik or ART as "allocation friendly", they don't perform escape analysis and if you do it constantly you'll be in a world of constant hard GC pauses. Multiple times over the years I've had to build free-lists in Java to avoid this specific problem. I don't know what you're doing, but I've generally found free-lists to be a net performance negative in Java libraries. Time and again, I've be…

Dalvik and ART have different behaviors than traditional Java VMs. Dalvik is aimed at low memory devices, ART trades some memory for speed but still is significantly different(i.e. it doesn't do escape analysis). As always benchmarking on hardware is the way to confirm this but I've had numerous cases where free lists or pre-allocated arrays has gained 10-30x performance improvements. Flatbuffers in particular excels…

Sure, with flatbuffers, I grok the case (though where possible I just use an off-heap mmap buffer for them anyway), but that's a very specific case.
Post reply on HN