Victor M.’s Post

my weekend rabbit hole this time: does Box<dyn Trait> actually matter in hot loops? built a pipeline with 8 operations running over 10 million floats. one version with Box<dyn Processor>, one with generics. same logic, same values, same machine. 118ms vs 13ms. WILD the vtable itself isn't even the problem, 2ns per call, genuinely irrelevant. the real issue is what it stops the compiler from doing. with dyn Trait it can't inline across steps, can't vectorize, can't use SIMD. just calls function pointers one by one. with generics it knows every type at compile time and goes crazy, fuses all the operations, auto-vectorizes the whole loop, multiple elements per cycle. same code. the compiler just had more information and used it. worth auditing if you have Box<dyn Trait> in anything performance sensitive. sometimes you need the flexibility. but if the types are known at compile time, you might be paying 10x for an abstraction you don't actually need repo below if you want to run it on your machine https://lnkd.in/drtUJTwq #rust #programming #performance #systems #lowlevel #softwaredevelopment #rustlang #softwareengineering #coding #techcommunity

  • text

quite interesting, I believe it depends on which layer that "dyn" is. I usually avoid Box<dyn ...> till the "Axum state" itself, so, I believe, most of the time it's everything wired at compile time. But maybe some of my "event interactors"/event handlers, for async works are using dyn where it could be avoided!

Lol, not surprised at all

Like
Reply
Ardial .

Software Engineer | Web3 & DeFi Developer | Full-Stack Developer | Frontend Developer | Backend Developer

3w

Wow, I’ve been using dynamic dispatch in go quite often, but I didn’t know it has such a big impact, nice post!! 👍

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories