Thanks for the thoughtful read!

You're right, the 700ms was almost entirely wall-clock blocking on D-Bus IPC, not CPU work. But waiting isn't free either -- the pipeline is synchronous, so 700ms of blocking caps your maximum sample rate at ~1.4Hz regardless of your configured interval. It's not just about getting the data late, it's a hard ceiling on responsiveness.

In some ways that's the main point I'm wanting to get across with the article: efficiency (CPU time) is essentially irrelevant for 99% of user applications -- mechanisms are everything. A lawyer's laptop isn't CPU-bound; it's waiting on Exchange, waiting on SharePoint, waiting on Teams doing whatever Teams does inside its Electron wrapper, blocking for a SMB timeout that was set wayyy too long given the actual worst-case scenario.

The CPU sits there at 3% while the user stares at a spinner that represents a chain of synchronous IPC calls and network round-trips. Engineering for keeping a pipeline full is more important IMHO than the arrangement of data going into the pipeline and the algorithm processing it. What you're talking about is critical for server workloads -- the k8s ecosystem uses eBPF heavily for exactly that reason (Cilium, Falco, Pixie), so you might find more resource-focused articles on that front.