You're correct. The point of O(f(n)) notation is asymptotic complexity. Intuitively, this measures how the runtime grows as the input grows--whether the solutio

You're correct. The point of O(f(n)) notation is asymptotic complexity. Intuitively, this measures how the runtime grows as the input grows--whether the solution does one pass or two over the input, doubling the input will double the runtime, so it's linear. Regarding the GP's approach in general, chasing constant-factor improvements on problems like this isn't always worth it. Doing one pass isn't necessarily faster than two if (for example) you do twice as much work at each step. Not to mention that measuring performance in "number of operations" is pretty vague to begin with unless you're digging all the way down to the generated assembly code and know how many clock cycles an ADD takes vs a MUL, etc. At that point you should probably just pull out a profiler =)