Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of value
I disagree; or rather, I'd put it the other way around by saying that often you can get both clean code (by some metric) and reasonable performance. The patterns in e.g. the book by Robert Martin doesn't give you either, though.
> And for most enterprise projects it just doesn't matter.
It matters for the users. I use software that is slow for no good reason, and I'd like to live in a world where this is not the case.
Make it run.
Make it clean. (and if need be,)
Make it fast.
Make it work
Make it right
Make it fast
My interpretation of this, so far, "make it right", is to make the code and design cleaner and refactor.
Then "make it fast" came into the play, iff, there was enough push.
uncle bob realized his "clean code" may have done a disservice with regards to performance. but i am not holding my breath on seeing a change come about soon.
it is possible to optimize for both performance and developer productivity. but everybody is leaving that out in the discussion.