When they are a direct path to horrible performance as you enter the area of L1 cache misses and vtavles on even an extremely simple function. It’s so weird to switch between working close to the hardware and working high above. Especially because Clean Code doesn’t actually seem easier to read or indeed maintain.
If it's not on the critical path, what difference does it make? Code outside the critical path should be optimizing for something and maintainability is as good as anything.
> Especially because Clean Code doesn’t actually seem easier to read or indeed maintain
If that is true, then there is indeed no point in applying Clean Code. But I disagree with GP that Clean Code leads automatically to bad performing code. That depends on your language and execution environment. A JVM is very good at effectively removing vtable indirection if they are not needed at runtime.
I don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one.
There's also other issues with this paradigm, like creating objects out of the arguments to a function.
That not only makes your code less maintainable (what if you need a subset of the variables), but now you'll have to drag all that data to each function you create.
Clean code is, IMO, worthless, data- and domain-driven design practices accomplish the goals of clean code better than it the paradigm itself does, and also improve other considerations like correctness and performance.
>I don't think a compiler could ever reliably transpose an array-of-structs representation to a struct-of-arrays one.
An interesting question, but a SoA isn't necessarily better than an AoS: it depends on the access pattern, so the question is whether this optimisation could be added as a part of PGO..
I'd also argue that even if vtable indirection can't be removed, it's unlikely to be a notable part of your performance profile, at least in the general case. Profile! You might instead see the hasher for your hash table has a much bigger.
The critical path can often be very wide and long and is not some small for loop deep down. Not all software is a video codec. Maintainability also does not necessarily exclude performance, smaller code can be easier to grasp and fit better into caches.
I’d argue that splitting what is essentially a four line check or default into something like three different functions makes it a lot harder to grasp.
I think my issue with clean code is primarily that it doesn’t actually make code more maintainable. As another poster mentioned, data or domain driven design does the same thing better.
If it's not on the critical path, what difference does it make? Code outside the critical path should be optimizing for something and maintainability is as good as anything.