test-infra VS bloaty

The trickiest part of decoding protobufs blind is how embedded messages and strings have the same tag type, but that's pretty easy to handle.

You can write a simple protobuf decoder in a couple hundred lines of code if you don't want to pull in the full protoc dependency: https://github.com/kubernetes/test-infra/blob/master/guberna... https://github.com/kubernetes/test-infra/blob/master/guberna...

Advanced tip: have a way for approved contributors to re-trigger CI. For example, Kubernetes, Kubeflow, and minikube use a tool called prow to run tests. Prow comes with a prow-bot that can accept different commands, automatically tagging issues or rerunning specific tests. Not for small projects, but this can alleviate maintainer headaches caused by trivial busy work.

It started as a small inside joke, but kinda just blew up. A bunch of us really loved UGG (which, if you haven’t played it, still highly recommend it even if you aren’t normally into video games), and as some of us have been known to do, take jokes a little too far/literal. A plug-in for the Kubernetes was built (https://github.com/kubernetes/test-infra/pull/14587) that posts goose pictures on command. Then there were some contests/activities put together at our contributor summit that were goose-themed.

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

ESP32s aren't really ‘lower level’ in the sense that anyone is likely to write assembly code for them (compared to, say, 8051 or PIC), other than maybe some driver author at Espressif. The big win from using RISC-V, other than name recognition, is mainstream compiler support (which is nothing to sneeze at, especially when it's largely funded by someone else).

When I worked on Matter¹, the Xtensa and RISC-V versions were basically fungible from the software point of view. (And really, so were other vendors' various ARMs.) We did find that Bloaty McBloatface² didn't support Xtensa, so I had to write an alternative.

¹ https://github.com/project-chip/connectedhomeip/

² https://github.com/google/bloaty

I’ve gotten good insight into what takes up space in binaries by profiling with Bloaty (https://github.com/google/bloaty). My last profiling session showed that clang’s ThinLTO was inlining too aggressively in some cases, causing functions that should be tiny to be 75 kB+.

I'm surprised they didn't go for the binary size analysis tools like

https://github.com/google/bloaty

Or goweight.

I was able to shave a few % off our app binary with Bloaty. It’s pretty hard to use but once you figure out how to make regular expressions to properly classify things from your codebase, you can really visually analyze what your binary is composed of.

Bloaty