this post was submitted on 08 Apr 2024
57 points (91.3% liked)
Rust
5654 readers
20 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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.
Easy solution: write tests to ensure equivalent behavior.