"Clean" Code, Horrible Performance

Summary

This video script critically examines the impact of common 'clean code' principles on software performance. The speaker argues that while these principles prioritize maintainability and readability, they often come at the cost of significant performance degradation. By comparing examples of polymorphism versus simpler code structures, the video demonstrates how adhering to clean code can slow down programs by up to 15x. The main takeaway is that developers should carefully balance code clarity with performance needs, especially for performance-critical applications.

Takeaways

• 😀 Clean code principles prioritize maintainability and readability, but they may significantly hinder software performance.
• 😀 Software performance issues arise due to the overhead of abstractions like polymorphism, which can make it hard for compilers to optimize.
• 😀 The 'Don't Repeat Yourself' (DRY) principle is valuable but can be counterproductive when it prevents optimization, such as in cases requiring different tables for performance.
• 😀 Clean code methods such as small functions and object-oriented principles often result in slower performance compared to more straightforward, less abstract approaches.
• 😀 A performance-sensitive approach might require breaking clean code principles, as highly abstracted code can be 15 times slower than code optimized for hardware utilization.
• 😀 In some scenarios, using a switch statement or direct code for performance-critical sections can be far more efficient than following object-oriented practices.
• 😀 While clean code improves long-term maintainability, it often sacrifices immediate performance gains by making code harder for compilers to optimize.
• 😀 Performance testing revealed that adhering strictly to clean code principles resulted in slower performance, sometimes over 15 times slower compared to alternative solutions.
• 😀 Optimized code can take advantage of hardware features like AVX instructions, which aren't utilized when sticking strictly to clean code principles.
• 😀 Developers should balance clean code practices with the need for high-performance software, understanding the trade-offs and context of each decision.

Q & A

Why does the speaker argue that clean code principles can slow down software performance?

The speaker argues that clean code principles, like minimizing repetition or using polymorphism, can introduce performance issues by creating additional overhead. For example, polymorphism involves virtual function calls and pointer indirection, which can significantly slow down performance compared to simpler, more direct methods like switch statements.

How does using polymorphism affect performance according to the speaker?

Polymorphism adds virtual function calls and pointer indirection, which results in slower performance. The speaker suggests that using a switch statement is much faster and provides a clearer and more direct execution path.

What is the performance difference between polymorphism and switch statements in the example provided?

The speaker claims that polymorphism can make the software 1.5x slower than using a switch statement, due to the overhead introduced by virtual function calls and pointer indirection.

How can a table-driven approach improve performance over the clean code principle of polymorphism?

A table-driven approach, which avoids the overhead of polymorphism, can lead to performance improvements by directly mapping data to operations. This method can result in 10x or even 15x better performance, especially in computation-heavy applications.

What does the speaker mean by 'clean code' potentially negating hardware performance advancements?

The speaker suggests that by adhering strictly to clean code principles, such as avoiding repeated code and prioritizing maintainability, we might sacrifice performance, effectively negating the improvements in hardware performance made over the years. Software written under these principles may fail to take full advantage of hardware capabilities.

What alternative to DRY (Don't Repeat Yourself) does the speaker suggest in performance-sensitive scenarios?

In performance-sensitive scenarios, the speaker suggests that repeating code might sometimes be necessary, such as when encoding similar data in multiple places for optimization purposes. This could lead to better performance even if it violates the DRY principle.

What is the significance of the speaker's criticism of clean code in performance-critical industries?

The speaker emphasizes that in performance-critical industries, prioritizing clean code principles over performance can be detrimental. For example, following strict rules that hinder optimization (like overusing polymorphism) can severely limit a program's efficiency, even though it might make the code more maintainable.

How does the speaker feel about 'Don't Repeat Yourself' (DRY) in the context of clean code?

The speaker is more lenient about the 'Don't Repeat Yourself' principle, acknowledging that while repetition can sometimes be inefficient, it might be necessary in cases where performance optimization is the priority. They argue that in these cases, breaking the DRY rule is justified.

What does the speaker suggest about the trade-off between clean code and performance?

The speaker suggests that while clean code principles may make software more maintainable, they often come at the cost of performance. In performance-critical systems, these trade-offs are unacceptable, and the primary focus should be on ensuring that code performs efficiently on modern hardware.

What is the speaker’s overall stance on following clean code principles in all scenarios?

The speaker advocates for a balanced approach, stating that clean code principles are valuable for maintaining code readability and ease of maintenance, but should not be followed at the expense of performance. In performance-critical situations, some principles (like polymorphism and DRY) should be reconsidered or avoided to ensure optimal software performance.