Code Smell 129 - Structural Optimizations

Photo by Priscilla Du Preez on Unsplash

Code Smell 129 - Structural Optimizations

We love to improve time and space complexity by guessing not real scenarios

Maxi Contieri
·Apr 12, 2022·

2 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Table of contents

  • Problems
  • Solutions
  • Context
  • Sample Code
  • Detection
  • Tags
  • Conclusion
  • Relations
  • More Info
  • Credits

TL;DR: Don't optimize anything until you have a real use scenario benchmark.

Problems

Solutions

  1. Cover your scenarios with tests.

  2. Write readable (and possible non-performant) code.

  3. Do a real benchmark with real user data. (No, iterating your code 100,000 times might not be a real use case).

  4. If you have conclusive data, you need to improve benchmark's found bottlenecks using Pareto principle.

  5. Attack the worst 20% problems causing 80% bad performance.

Context

At university and online courses, we learn algorithms, data structures, and computational complexity before good design rules.

We tend to overestimate the (possible) performance problems and underestimate code readability and software lifetime.

Premature optimization often has no evidence of solving real problems.

We need to surgically improve our code when the facts tell us we have a real issue.

Sample Code

Wrong

for (k = 0; k < 3 * 3; ++k) {
     i = Math.floor(k / 3);
     j = k % 3;
     console.log(i + ' ' +  j);
  }

//This criptic piece of code iterates a 
//two dimensional array
//We don't have proofs this will be useful
//In real contexts

Right

for (innerIterator = 0; innerIterator < 3; innerIterator++) {
  for (outerIterator = 0; outerIterator < 3; outerIterator++) {
   console.log(innerIterator + ' ' +  outerIterator);
  }
 }

// This is a readable double for-loop
// 3 is a small number
// No performance issues (by now)
// We will wait for real evidence

Detection

[X] Manual

This is a semantic smell.

We might find the code is harder to read.

Tags

  • Premature Optimization

Conclusion

We need to stop optimizing for machines and start optimizing for humans readers and code maintainers.

We need to avoid programming languages designed for premature optimization and favor robust ones.

Relations

More Info

Credits

Photo by Priscilla Du Preez on Unsplash


Optimism is an occupational hazard of programming: feedback is the treatment.

Kent Beck


This article is part of the CodeSmell Series.

 
Share this

Impressum

Technical Opinions are my own. I don't have the revealed truth.

Software Design is a creative activity. These are hints and not rigid rules.

I write on BackEnd Business Systems and OOP Design. My advice/experience might not suit other systems.

You can write me at info(at)maximilianocontieri.com