0

Solving my homework for Informatics at University, I always find different ways to solve the same problem. One way is the fastest(execution time) but the longest and more complex. And the other is way easier to realize, falls short in execution time, it's easy to understand and so on.

As an mini-example is that we have have to create a program in C++, which outputs a line of N elements where each element has same adjacent elements different of that in the middle.

Ex.    
6 Elements: *_*_*_
7 Elements: *_*_*_*

First solution is the easiest:

#include <iostream>
using namespace std;

int main(void){
    int a;
    cin >> a;
    for (int i=1; i<=a; i++)
    {
        if (i%2 != 0)
        {
            cout << "*";
        }
        else
        {
            cout << " ";
        }
    }
    return 0;
}

And the second one is a little bit harder to implement but faster to execute(less conditionals checks):

#include <iostream>
using namespace std;

int main(void){
    int a;
    cin >> a;
    if (a%2 == 1)
    {
        for (int i=1; i<=a; i=i+2)
        {
            cout << "*";
            cout << " ";
        }
    }
    else
    {
        for (int i=1; i<a; i=i+2)
        {
            cout << "*";
            cout << " ";
        }
        cout << " ";
    }
    return 0;
}

My question is what should I focus on? Clean code, easy to implement/deploy and better readability or best algorithm, faster to execute and strong logic, or just try as best as possible to mix all these 2, because there is always a discrepancy between these 2 ways of solving problems?

DomainFlag
  • 563
  • 2
  • 9
  • 22
  • 1
    I'd go for solution 2 with only one cout for better speed :) `for (int i=1; i<=a; i=i+2) { cout << "* "; }` BTW I believe there's a typo in example 2: both loops issue the star & space in the same order. – Jean-François Fabre Sep 17 '16 at 16:08
  • Nice notice ;), the space was as an example, let's say instead of space is "-" – DomainFlag Sep 17 '16 at 16:10
  • 1
    I don't see any reason to have 2 loops for the second version, why not just put the conditional at the end? – perreal Sep 17 '16 at 16:11
  • My advice: avoid copy/paste, and avoid tests in the inner loop. None of your both examples achieve this. – Jean-François Fabre Sep 17 '16 at 16:15
  • 2
    Optimization depends on the project. In consumer products, the aim is to get the software completed A.S.A.P.; so getting a working version is top priority and speed is a lesser priority. In Event Critical applications, where timing is important, speed can be very important. There is no golden rule for everything. – Thomas Matthews Sep 17 '16 at 16:26
  • One optimization trick is to *build* your text rows into strings, then output the strings. This reduces the calls to `cout` from once for each character to one per row. Calling functions has an overhead, and reducing the overhead can speed up your program. – Thomas Matthews Sep 17 '16 at 16:28
  • 1
    There is no difference between the `for` loops, so get rid of one of them. Less code means less possible defects and less time to test your code. – Thomas Matthews Sep 17 '16 at 16:30
  • 1
    This question has been asked several times at least. It is a false dichotomy to think you have to trade off clarity for performance. Also, performance is never where you think it is, so you have to find it in the running of the program, not in the writing. [*Here is a good way to do it.*](http://stackoverflow.com/a/378024/23771) – Mike Dunlavey Sep 17 '16 at 16:34

1 Answers1

4

You should try to write readable, easy to debug code for an ease of understanding.

Whenever you encounter portions of code where it can be heavily optimized in order to get much higher performance (either by modifying the code's architecture or/and by implementing assembly in your code), you can add in a commented section the better performance alternative of it. Even if you choose the better performance alternative, you'll always have the other one which can back up you up, in order to understand it.

Also, stick to better performance alternatives when you can see huge gains by doing it so, not every time.

Keep in mind that these improvements are better to be only implemented in the case of performance bottlenecks or in systems where power efficiency is crucial.

Robert Lucian Chiriac
  • 686
  • 2
  • 15
  • 24