"Clean" Code, Horrible Performance in Rust (chrs.dev)

submitted 7 months ago by chrs@programming.dev to c/rust@programming.dev

25 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] gedhrel@lemmy.world 43 points 7 months ago

Casey's video is interesting, but his example is framed as moving from 35 cycles/object to 24 cycles/object being a 1.5x speedup.

Another way to look at this is, it's a 12-cycle speedup per object.

If you're writing a shader or a physics sim this is a massive difference.

If you're building typical business software, it isn't; that 10,000-line monster method does crop up, and it's a maintenance disaster.

I think extracting "clean code principles lead to a 50% cost increase" is a message that needs taking with a degree of context.

[-] sugar_in_your_tea@sh.itjust.works 15 points 7 months ago

Yup. If that 12-cycle speedup is in a hot loop, then yeah, throw a bunch of comments and tests around it and perhaps keep the "clean" version around for illustrative purposes, and then do the fast thing. Perhaps throw in a feature flag to switch between the "clean" and "fast but a little sketchy" versions, and maybe someone will make a method to memoize pure functions generically so the "clean" version can be used with minimal performance overhead.

Clean code should be the default, optimizations should come later as necessary.

[-] coloredgrayscale@programming.dev 1 points 7 months ago

Keeping the clean version around seems dangerous advice.

You know it won't get maintained if there are changes / fixes. So by the time someone may needs to rewrite the part, or application many years later (think migration to different language) it will be more confusing than helping.

[-] sugar_in_your_tea@sh.itjust.works 5 points 7 months ago

Easy solution: write tests to ensure equivalent behavior.

[-] bonus_crab@lemmy.world 5 points 7 months ago

For what its worth , the cache locality of Vec<Box> is terrible in general, i feel like if youre iterating over a large array of things and applying a polymorphic function you're making a mistake.

Cache locality isnt a problem when youre only accessing something once though.

So imo polymorphism has its place for non iterative-compute type work, ie web server handler functions and event driven systems.