Date: Wed, 1 Mar 2023 12:42:32 +0000
Part of the issue here is that we have normalized so much of this decades-old advice that the comparisons are not what they once were.
Take a simpler piece of advice like declaring things immediately before you use them, or at least closer to where you use them. I’ve had arguments and pushback on this from people who are writing functions that are at most 20 lines long. When I tell them about 5000 line functions they just can’t believe me. And the worst of those functions that were thousands of lines long always seemed to have a giant switch, with each case screens and screens long, or nested loops again screens and screens long. The two cases presented in this article (I read it yesterday and immediately wanted to ask some experts their thoughts) are short and sweet. But Clean Code and the like weren’t comparing those two possibilities. They were comparing a 5000 line function to 5 1000 line functions, which you might break down a little further.
There are two actually-reasonable points buried in the article. One is that virtual functions can’t be inlined and the other that using pointers to achieve polymorphism means there’s a good chance you’re allocating on the heap and may not be allocating contiguously, which means you won’t get cache and prefetch benefits. However they seem unaware that in an application that actually does something, these effects will not be anywhere near as large as what they measured here. But more importantly, all that talk of going back in time, they went back in time to “solve” their problem, turning to C as so many perf-heads do.
Is anyone willing to do the compile-time polymorphism approach (with templates) on this example and do the same measurements? I think you could regain inlining (no virtual functions) and lose the pointer-related issues too.
From: SG20 <sg20-bounces_at_[hidden]g> On Behalf Of JC van Winkel via SG20
Sent: Wednesday, March 1, 2023 3:40 AM
To: SG20 <sg20_at_[hidden]>
Cc: JC van Winkel <jcvw_at_[hidden]>
Subject: [SG20] "Clean" Code, Horrible Performance
Hi,
I came across this article<https://www.computerenhance.com/p/clean-code-horrible-performance> (summary of a video<https://www.youtube.com/watch?v=tD5NrevFtbU>) that says that we are teaching people the wrong things.
My feeling is that the presenter is cherry picking the worst possible examples and values micro-optimizations over maintainability and I wonder how often the presenter has worked on really large code bases...
JC
Take a simpler piece of advice like declaring things immediately before you use them, or at least closer to where you use them. I’ve had arguments and pushback on this from people who are writing functions that are at most 20 lines long. When I tell them about 5000 line functions they just can’t believe me. And the worst of those functions that were thousands of lines long always seemed to have a giant switch, with each case screens and screens long, or nested loops again screens and screens long. The two cases presented in this article (I read it yesterday and immediately wanted to ask some experts their thoughts) are short and sweet. But Clean Code and the like weren’t comparing those two possibilities. They were comparing a 5000 line function to 5 1000 line functions, which you might break down a little further.
There are two actually-reasonable points buried in the article. One is that virtual functions can’t be inlined and the other that using pointers to achieve polymorphism means there’s a good chance you’re allocating on the heap and may not be allocating contiguously, which means you won’t get cache and prefetch benefits. However they seem unaware that in an application that actually does something, these effects will not be anywhere near as large as what they measured here. But more importantly, all that talk of going back in time, they went back in time to “solve” their problem, turning to C as so many perf-heads do.
Is anyone willing to do the compile-time polymorphism approach (with templates) on this example and do the same measurements? I think you could regain inlining (no virtual functions) and lose the pointer-related issues too.
From: SG20 <sg20-bounces_at_[hidden]g> On Behalf Of JC van Winkel via SG20
Sent: Wednesday, March 1, 2023 3:40 AM
To: SG20 <sg20_at_[hidden]>
Cc: JC van Winkel <jcvw_at_[hidden]>
Subject: [SG20] "Clean" Code, Horrible Performance
Hi,
I came across this article<https://www.computerenhance.com/p/clean-code-horrible-performance> (summary of a video<https://www.youtube.com/watch?v=tD5NrevFtbU>) that says that we are teaching people the wrong things.
My feeling is that the presenter is cherry picking the worst possible examples and values micro-optimizations over maintainability and I wonder how often the presenter has worked on really large code bases...
JC
Received on 2023-03-01 12:42:35