<story><title>A new ProtoBuf generator for Go</title><url>https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/</url></story><parent_chain></parent_chain><comment><author>jupp0r</author><text>Using CPU utilization as a performance metric can be extremely misleading. My favorite article on the subject is from Brendan Gregg:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.brendangregg.com&amp;#x2F;blog&amp;#x2F;2017-05-09&amp;#x2F;cpu-utilization-is-wrong.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.brendangregg.com&amp;#x2F;blog&amp;#x2F;2017-05-09&amp;#x2F;cpu-utilization-...&lt;/a&gt;&lt;p&gt;A much better way to test the influence of the new compiler would be to test the actual throughput at which saturation is achieved (which is what the benchmark in the C++ grpc library measure to assess their performance).</text></comment>
<story><title>A new ProtoBuf generator for Go</title><url>https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/</url></story><parent_chain></parent_chain><comment><author>jzelinskie</author><text>I hadn&amp;#x27;t realized that Gogo was in such a bad spot with the upstream Go protobuf changes. There was lots of drama when the changes were made and I guess that overshadowed any optics I had on Gogo.&lt;p&gt;Making vtprotobuf an additional protoc plugin seems like the Right Thing™, although it&amp;#x27;s a shame how complicated protoc commands end up becoming for mature projects. I&amp;#x27;m pretty tempted to port Authzed over to this and run some benchmarks -- our entire service requires e2e latency under 20ms, so every little bit counts. The biggest performance win is likely just having an unintrusive interface for pooling allocated protos.</text></comment>