3 ms·

One of the the points of "clean code" is to make it easy to find the hotspots and optimize those. Write the codebase at a very high level, plenty of abstraction

One of the the points of "clean code" is to make it easy to find the hotspots and optimize those. Write the codebase at a very high level, plenty of abstractions etc. and then optimize the 1% that really needs it. Optimizing a small piece of software is not going again clean code, on the contrary, it re-enforces it: you can spend the time to optimize only what is necessary.

TeMPOraL 4y ago
One of the main points of Casey's videos is that following the "clean code" mantras will make your code unoptimizable. You may delay performance considerations until the end, then fire your profiler, find that 1% that really needs it[0], ... and realize that you can't get more than 1.5x - 2x speedup without ripping out the core 10% of the codebase and rethinking it properly. Were you, however, to consider performance from the start, that 10% would've been designed around completely different abstractions, and already 10x faster in the unoptimized version. "Clean Code" should be called pessimistic coding - a big part of it is to enable OK flexibility in any imaginable direction. But real-life code will not change in all possible direction - in fact, you can predict quite well roughly what can and cannot change. Writing for performance means, among other things, making things easier both for human and the CPU by reducing flexibility in the unlikely directions. In the toy example from the video: Casey's proposed alternatives baked in the assumption that the program is working with shapes which, for a given computation, all can fit a specific family of equations. Clean code will make it just as easy to add a square as to add a parametric spline surface. Casey's code will make the former trivial, the latter hard without redoing the entire shape-related code. It's a good tradeoff if you're making a program that mostly works with non-parametric simple polygons, because nobody will need parametric splines in it. On the off chance they will, they can pay for the extra effort - and in the meantime, your software is 20x faster than the equivalent "clean code" version. -- [0] - This thinking alone is a problem. It's not the 1% that needs some optimization work. The entire user-interacting surface and everything downstream of it need it, which means effectively the entire program. You're free to set a cut-off point beyond which you don't care about "less important" features - but 1% seems quite too early.
whstl 4y ago
"One of the the points of "clean code" is to make it easy to find the hotspots and optimize those" Where is this in the book? I can't find a single mention of "hotspot" in the book, and even "optimizations" only shows up 3 times.

TeMPOraL 4y ago

One of the main points of Casey's videos is that following the "clean code" mantras will make your code unoptimizable. You may delay performance considerations until the end, then fire your profiler, find that 1% that really needs it[0], ... and realize that you can't get more than 1.5x - 2x speedup without ripping out the core 10% of the codebase and rethinking it properly. Were you, however, to consider performance from the start, that 10% would've been designed around completely different abstractions, and already 10x faster in the unoptimized version. "Clean Code" should be called pessimistic coding - a big part of it is to enable OK flexibility in any imaginable direction. But real-life code will not change in all possible direction - in fact, you can predict quite well roughly what can and cannot change. Writing for performance means, among other things, making things easier both for human and the CPU by reducing flexibility in the unlikely directions. In the toy example from the video: Casey's proposed alternatives baked in the assumption that the program is working with shapes which, for a given computation, all can fit a specific family of equations. Clean code will make it just as easy to add a square as to add a parametric spline surface. Casey's code will make the former trivial, the latter hard without redoing the entire shape-related code. It's a good tradeoff if you're making a program that mostly works with non-parametric simple polygons, because nobody will need parametric splines in it. On the off chance they will, they can pay for the extra effort - and in the meantime, your software is 20x faster than the equivalent "clean code" version. -- [0] - This thinking alone is a problem. It's not the 1% that needs some optimization work. The entire user-interacting surface and everything downstream of it need it, which means effectively the entire program. You're free to set a cut-off point beyond which you don't care about "less important" features - but 1% seems quite too early.

whstl 4y ago

"One of the the points of "clean code" is to make it easy to find the hotspots and optimize those" Where is this in the book? I can't find a single mention of "hotspot" in the book, and even "optimizations" only shows up 3 times.