21–30 of 72 posts
One great use of agentic coding is being able to add and very granular tracing instrumentation to help with these sort of optimizations.
Also a great way to make sure that your app spends most of its time in observability overhead. For example even the latency histogram that the OP mentions is wildly expensive.
Earlier quoted context omitted.
I'm just reporting from the trenches here. I think you are suggesting that everyone is aware of and capable of using state-of-the-art (from 20 years ago) tracing schemes like XRay[1], when in reality they are not. Most projects would be well-served by any basic profiler but even profiling is apparently for wizards, because I've seen a lot of projects that will resort to manually annotating functions with OTel trace s…
Not even an analog: https://doc.rust-lang.org/beta/unstable-book/compiler-flags/... It's worth pointing out though that just tracing function calls isn't good enough for the kinds of stackless coroutines that run in async Rust tasks. You need a way of mapping between the async tasks and the compiler emitted traces. afaik, C/C++ have the same problem.
For a true high performance you should use thread busy-spinning, CPU pinning and SPSC/MPSC ring buffers.
Earlier quoted context omitted.
Also a great way to make sure that your app spends most of its time in observability overhead. For example even the latency histogram that the OP mentions is wildly expensive.
Was this in a specific application? I wouldn't necessarily expect that histogram to be particularly bad for most applications.
Earlier quoted context omitted.
Also a great way to make sure that your app spends most of its time in observability overhead. For example even the latency histogram that the OP mentions is wildly expensive.
Just curious, why? Is this true even if you did something like a per-CPU histogram that uses atomic ops to increment?
For a true high performance you should use thread busy-spinning, CPU pinning and SPSC/MPSC ring buffers.
All of these are different, valid, meanings of high performance. You need context. An interactive IDE is yet another thing that needs to be high performance in yet another way.
The other trick I've used a few times that's a bit hacky but can get the job done is when reading a snapshot of the data under a mutex is enough without needing to prevent other changes; if that's the case, you can just clone the data and drop the mutex to allow other uses move forward at the cost of the data potentially being stale.
When you're at a point of tuning Tokio, consider taking a look at ef_vi/DPDK + SPDK
Earlier quoted context omitted.
Not even an analog: https://doc.rust-lang.org/beta/unstable-book/compiler-flags/... It's worth pointing out though that just tracing function calls isn't good enough for the kinds of stackless coroutines that run in async Rust tasks. You need a way of mapping between the async tasks and the compiler emitted traces. afaik, C/C++ have the same problem.
The difference is nobody in the C++ community believes that a dominant asynchronous executor library exists, and there is not a pervasive belief that it would be helpful.
But honestly that's a mischaracterization of the situation in Rust. Tokio is popular for networked service backends. If that's the wheelhouse you're in then yea it might look "dominant."