Rust

6025 readers

1 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

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

submitted 7 months ago by chrs to c/rust

25 comments fedilink hide all child comments

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

[–] [email protected] 43 points 7 months ago (2 children)

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.

[–] [email protected] 15 points 7 months ago (1 children)

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 1 points 7 months ago (1 children)

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.

[–] [email protected] 5 points 7 months ago

Easy solution: write tests to ensure equivalent behavior.

[–] [email protected] 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.