Why 'indirection has a cost' is usually the wrong reason to inline and what actually costs you.

Hacker News is a community-driven platform for sharing and discussing technology news, startups, and programming-related topics. Through user submissions and comments, Hacker News offers insights into emerging technology trends, industry developments, and entrepreneurial ventures. Readers can participate in discussions, share their insights, and stay informed about the latest advancements in technology and innovation.

Hacker News

Function call indirection in Rust async code is almost never a real performance concern. The Rust compiler in release mode frequently inlines extracted helper functions, producing identical assembly to inlined code. The actual costs worth worrying about are I/O, locks, and allocations — not function call boundaries, which cost only a few CPU cycles. Real indirection overhead only matters in tight inner loops, with dyn Trait dynamic dispatch, or in explicitly performance-critical paths. The post argues that premature inlining sacrifices code readability, testability, and maintainability for no measurable gain, and recommends using profilers like callgrind or perf to verify actual bottlenecks before optimizing. The right approach is to extract well-named functions, trust the optimizer, and only reach for #[inline] when profiler data justifies it.

The Cost of Indirection in Rust

<p>Very interesting take, I will have to think on it some more.</p>
