Let's look at a simple implementation of linear search:
var doLinearSearch = function(array, targetValue) {
  for (var guess = 0; guess < array.length; guess++) {
    if (array[guess] === targetValue) { 
        return guess;  // found it!
    }
  }
  return -1;  // didn't find it
};
Let's denote the size of the array (array.length) by n n . The maximum number of times that the for-loop can run is n n , and this worst case occurs when the value being searched for is not present in the array.
Each time the for-loop iterates, it has to do several things:
  • compare guess with array.length
  • compare array[guess] with targetValue
  • possibly return the value of guess
  • increment guess.
Each of these little computations takes a constant amount of time each time it executes. If the for-loop iterates n n times, then the time for all n n iterations is c1n c_1 \cdot n , where c1 c_1 is the sum of the times for the computations in one loop iteration. Now, we cannot say here what the value of c1 c_1 is, because it depends on the speed of the computer, the programming language used, the compiler or interpreter that translates the source program into runnable code, and other factors.
This code has a little bit of extra overhead, for setting up the for-loop (including initializing guess to 0) and possibly returning -1 at the end. Let's call the time for this overhead c2 c_2 , which is also a constant. Therefore, the total time for linear search in the worst case is c1n+c2 c_1 \cdot n + c_2 .
As we've argued, the constant factor c1 c_1 and the low-order term c2 c_2 don't tell us about the rate of growth of the running time. What's significant is that the worst-case running time of linear search grows like the array size n n . The notation we use for this running time is Θ(n) \Theta(n) . That's the Greek letter "theta," and we say "big-Theta of n n " or just "Theta of n n ."
When we say that a particular running time is Θ(n) \Theta(n) , we're saying that once n n gets large enough, the running time is at least k1n k_1 \cdot n and at most k2n k_2 \cdot n for some constants k1 k_1 and k2 k_2 . Here's how to think of Θ(n) \Theta(n) :
For small values of n n , we don't care how the running time compares with k1n k_1 \cdot n or k2n k_2 \cdot n . But once n n gets large enough—on or to the right of the dashed line—the running time must be sandwiched between k1n k_1 \cdot n and k2n k_2 \cdot n . As long as these constants k1 k_1 and k2 k_2 exist, we say that the running time is Θ(n) \Theta(n) .
We are not restricted to just n n in big-Θ notation. We can use any function, such as n2 n^2 , nlog2n n \log_2 n , or any other function of n n . Here's how to think of a running time that is Θ(f(n)) \Theta(f(n)) for some function f(n) f(n) :
Once n n gets large enough, the running time is between k1f(n) k_1 \cdot f(n) and k2f(n) k_2 \cdot f(n) .
In practice, we just drop constant factors and low-order terms. Another advantage of using big-Θ notation is that we don't have to worry about which time units we're using. For example, suppose that you calculate that a running time is 6n2+100n+300 6n^2 + 100n + 300 microseconds. Or maybe it's milliseconds. When you use big-Θ notation, you don't say. You also drop the factor 6 and the low-order terms 100n+300 100n + 300 , and you just say that the running time is Θ(n2) \Theta(n^2) .
When we use big-Θ notation, we're saying that we have an asymptotically tight bound on the running time. "Asymptotically" because it matters for only large values of n n . "Tight bound" because we've nailed the running time to within a constant factor above and below.

This content is a collaboration of Dartmouth Computer Science professors Thomas Cormen and Devin Balkcom, plus the Khan Academy computing curriculum team. The content is licensed CC-BY-NC-SA.
Loading