When Clean Code Hurts Performance: Tips For Crushing Common Challenges
Casey Muratori, a Seattle-based programmer, started a discussion in the programming world about some lengthy ideas about best practices.
“Many programming ‘best practices’ taught today are performance problems waiting to happen,” Seattle-based programmer Casey Muratori warned on his educational website, creating a discussion among programmers.
Some agreed some disagreed, but active internet discussions began, with programmers from all over the web examining or supporting lengthy ideas about best practices.
Muratori gave away a free “bonus video” specifically focused on the performance penalty of so-called “clean code” practices, or the long list of well-established rules of not doing things in a certain way, to promote a $9-a-month series of videos on YouTube named “Performance-Aware Programming.”
According to Muratori, these practices don’t necessarily boost the efficiency of the resulting application.
The following discussion raised the topic of what standard should be used to judge code effectiveness…
Muratori discovered the following limitations to some people will remember best practices for creating code:
Changing something
For cleaner code, programmers are often told to stay away from code blocks that list out each potential fork that the flow could take, such as switch statements in C, which create a separately-coded case for every potential value for a variable.
It’s a common disagreement among clean code supporters:
- Switch statements, according to programmer Arnold Abraham, are “unhandy and bloat your code.”
- Clean Code supporter Robert C. Martin speaks to the development of switch statements as “a common problem in software systems,” pointing out that it’s simple to ignore a case while changing code, leading to brittle systems. (More importantly, the results of each fork in the flow are usually hidden in lower-level modules.)
- According to the “Refactoring Guru” website, avoiding switch statements will boost your “code structure.”
Muratori put this to the test by using a common example used by clean code supporters.
He offers a function in his video that counts the area of four forms.
The “clean code” method involves four clean class designs that include area-calculating code for each different shape.
Muratori compares its performance with that of a single function that delivers a line of code for each of the four potential forms.
What were the results? Muratori’s performance testing reveals a 1.44x speed boost.
Even so, as Muratori shows in the video, there’s another advantage.
“When your code is structured by function rather than type, it’s easy to spot and extract common patterns.”
In comparison, some clean code supporters even separate the code for specific types into separate files.
“The more complex the problem, the more these concepts hurt your performance.” Casey Muratori’s
In this case, calculating the area of the four forms always involves multiplying a width by a height, but with a shape-specific multiplier such as pi for a circle or one-half for a triangle.
When all four calculations are close to each other in adjoining lines of code, it’s much easier to swap in a quick lookup table for the one thing that differs across all four cases.
“Not only is it a lot quicker, but it’s also far less semantically complex,” Muratori said in the video.
“There are fewer tokens, operations, and lines of code.”
Muratori’s benchmarks now show a 10x boost in speed…
“The more complex the problem gets, the more these ideas hurt your performance,” Muratori said.
“As you try to scale up ‘clean’ techniques to real objects with many properties, you will see these systemic performance penalties throughout your code…”
Muratori believes it is more than an intellectual question.
“If your code runs on a server ‘in the cloud,’ your monthly fee is directly proportional to the performance of your software,” he said in his introductory blog post.
“The math is simple: the slower your program, the more server time (or servers in general) you must buy…”
Even more, cases are given in the video series, but Muratori’s conclusion is clear.
“The answer to ‘why is software so slow’ for a certain segment of the tech world is in large part ‘because of “clean” code.”
The ideas underlying the ‘clean’ coding style are almost all bad for performance and should be ignored….”
In response to a New Stack question, Muratori said that he thinks clean code supporters don’t properly understand how CPUs work — and don’t understand “the depth of the performance costs of their ideas…”
Getting a Response
Not everyone believes.
When Muratori’s post was discussed on Hacker News, it got 739 upvotes and 907 comments, with some users suggesting Muratori’s perspective was misinformed because of his work on game engine optimization.
Graphics programmer Daniel Kvick also works on game optimization and remarked that the company’s ongoing focus on GPU performance “is another beast” than CPU optimization.
And developer Jonathan Dickinson argued that game makers “had the luxury of starting from near-scratch now and again…
I’m guessing things wouldn’t be so clear-cut if he was handed a 10-year-old codebase to work on.”
Nonetheless, software developer Joshua Rumbut appreciated Muratori’s flexibility in the face of what are normally stringent rules for programmers.
“One of the good things about some of the clean code ideas he uses is that, as he shows, you can tactically step back from them in key, performance important areas and enjoy these rewards.”
Hasen Judi, a web programmer, expressed a more general problem with those concepts.
“I’ve never seen a codebase created with ‘clean code’ ideas in mind that are both maintainable and easy to develop over.”
“Part of the response was troubling since so many opposing opinions seemed to be based on factual errors,” Muratori told The New Stack, “but overall I was inspired by the surprisingly large number of people who dislike ‘clean code’ and want to do something about it.”
It could look promising…”
Muratori released the whole text of his detailed response public, as well as a lengthy but friendly two-part GitHub discussion with Robert C. Martin, author of the 2009 book Clean Code: A Handbook of Agile Software Craftsmanship.
Martin agreed that Muratori’s “Clean Code” examples “are not efficient at the millisecond level,” but questioned whether it was important.
“This would have been important a long time ago.” We were worried about the cost of indirection and function call overhead.
If we could, we would remove loops. This was especially true in real-time embedded systems.
All the same, the environments in which such efficiency is needed are becoming rarer and rarer.”
Muratori, on the other hand, perfectly described his perspective in a recent interview on the YouTube channel ThePrimeTime.
“Together with optimizing code, we can also pessimize code.
We can do things that make it even harder for the CPU to run it for no apparent reason…
Because of some other weird metrics that I’m not sure where they come from — like clean code — that I don’t think anyone has ever proven truly made someone more productive, but I can prove they make the CPU less productive, so it seems like a bad deal.”
So, what comes next?
“The response to the video has been rather positive,” Muratori told the New Stack.
“I have got a large number of ‘thank you’ emails from folks who disagree with ‘clean code’ approaches not just because of their poor performance, but also because they do not offer the apparent benefits (readability, maintainability, etc.) in reality.”
Before you bounce, consider leaving a $1 coffee for the road!
