Why more lines of code sometimes deliver better performance than few lines of code?

When we see different ways to write a program, we often think that shorter version of code is much better than longer version code. We assume that shorter code runs faster than the longer one . But this isn’t always true. Lets find out why .

Assuming we have 9 balls, where 8 are of equal weight (say, 5), and one is heavier (weight 7). Find the heaviest ball among all . How do we write this in code ?

Let’s compare two approaches that solve this problem in different ways.

Approach 1 : smaller version

Comparing each ball one by one(linear search method).

int findHeaviest(){
//assuming all weigh 5 except one, which is heavier (7)
int ball[9] ={5,5,5,5,5,5,5,7,5};

for(int i = 0; i < 9; i++){
    if(ball[i] > 5){
     return ball[i];
    }
}

Observe what is happening in approach 1:

We are comparing each ball one by one and in In the worst-case scenario, the heaviest ball is at last place requiring 9 comparisons.

Total: 9 comparisons (worst case).

Approach 2 : longer version

int findHeaviest(){

//assuming all weigh 5 except one, which is heavier (7)
int ball[9]={5,5,5,5,5,5,5,7,5};

//dividing the balls into three individual groups a,b & c.
int a = ball[0]+ ball[1]+ball[2];//group a: balls 0,1,2
int b = ball[3]+ ball[4]+ball[5];//group b: balls 3,4,5
int c = ball[6]+ ball[7]+ball[8];//group c: balls 6,7,8


//check if a and b are equal
if(a == b){
//if a and b are equal check in c.
    if(ball[6] > ball[7]){
        return ball[6];
    }else if(ball[7] > ball[6]){
        return ball[7];
    } else{
        return ball[8];
    }

}else if(a > b){
// If group a is heavier, check in a.
    if(ball[0] > ball[1]){
        return ball[0];
    }else if(ball[1] > ball[0]){
        return ball[1];
    }else {
        return ball[2];
    }

}else{
//If group b is heavier, check in b.
    if(ball[3]> ball[4]){
        return ball[3];
    }else if(ball[4] > ball[3]){
        return ball[4];
    }else{
        return ball[5];
    }
}
}

Observe what is happening in approach 2: (divide and conquer)

There can only be 3 cases to the find heaviest ball.

case 1: if a == b , 6 balls rejected . it means heaviest ball is in group c. and comparing the remaining 3 balls in c .

case 2: if a > b (ball is in a ), comparing balls in a .

case 3: if a < b( ball is in b). comparing balls in b.

Total Comparisons

• Step 1: Group comparison: 1 or 2 (since if a == b is false, only then a > b is checked).

• Step 2: Within-group comparison: 2 (to find the heaviest among three balls).

So, in the worst case, the code performs:

• 2 group comparisons (to determine which group has the heavy ball)

• 2 within-group comparisons (to find the heaviest among three balls)

Total: 4 comparisons (worst case).

Key Take aways :

1 : Approach 2 is quicker than Approach 1 .because it requires fewer comparisons.

2 : Just because one program has 100 lines of code and another has only a few, you can’t judge which will run faster based solely on the length of the code. The number of lines doesn’t always reflect the actual performance.

So, how can you really tell how long code takes to run?

For that, there’s a concept called time complexity, which helps estimate the running time of code. I’ll explain more about time complexity in my next blog—stay tuned, and thank you!