Time-complexity derivation procedure in generic way for algorithms

Question

I have been reading a lot of articles on data structures and algorithms and everyone only says the most generic way of calculating the time complexity and is usually defined as the time taken for the execution considering variations in input and to iterate an array of n elements let the code be as below and the Big-O complexity is O(n).

 for (int i=0;i<a.length;i++)
   System.out.println(a[i]);

Agreed thats the way of calculating the time complexity but what about recursive algorithms and how does one come to the conclusion of logarithmic expressions and stuff while calculating time complexity. There is no standard that I came across or aware of so far for deriving those complexities. If yes can someone please throw some light or refer me where to start.

Thanks in advance. Please don't mark as duplicate as there could be many who are facing the same issue of understanding and derving time-complexities after getting tired from different tutorials on web.

Answer 1

Unfortunately, there's no general-purpose algorithm you can follow that, given an arbitrary piece of code, will tell you its time complexity. This is due, in part, to the fact that there's no general way to determine whether an arbitrary piece of code will even halt in the first place. If we could take an arbitrary piece of code and work out its time complexity - assuming it even has one - we could potentially use that to determine whether it would terminate, and that's not something we can do.

As an example of why this is hard, consider this piece of code:

int n = /* get user input */
while (n > 1) {
    if (n % 2 == 0) n /= 2;
    else n = 3*n + 1;
}

This code traces out the "hailstone sequence" starting at the user's number n. Surprisingly, no one knows whether this process always terminates , and so no one currently has any upper bound at all on how many steps this loop is going to take to terminate.

In practice, working out how long a piece of code takes to run requires a mix of different techniques. For example, the Master Theorem is helpful in determining how long it takes for many recursive functions to terminate. For other, more complex recursive functions, we can often write out a recurrence relation for the runtime, then use a battery of techniques to solve those recurrences. Sometimes it's helpful to work from the inside out, replacing inner loops with simpler expressions and seeing what comes out. Sometimes, it's important to know useful summations like 1/1 + 1/2 + 1/3 + ... + 1/n = Θ(log n), or that 2 ⁰ + 2 ¹ + ... + 2 ^k = Θ(2 ^k ). Sometimes, you work out the runtime by thinking about how the code works and what each step does. And sometimes, it takes years to work out just how fast a piece of code is.