Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

All the languages I know of would execute something like:

i = 0
while i < 100000000
    i += 1

..and you can see it take a noticeable amount of time to execute.

Why though, do languages do this? The only effect this code will have is taking time.

edit: I mean inside a function which is called

function main(){
function useless(){
    i = 0
    while i < 100000000
        i += 1
share|improve this question
Perhaps taking time is the desired effect of such code? –  Bill Michell Jun 20 '12 at 17:59
How is that loop effect-less? If the loop does not execute, i will stay 0. If it does execute, i will be 100000000. So clearly you can't just remove the loop. You could replace it with i = 100000000 though (and that's exactly what gcc does if optimizations are enabled). –  sepp2k Jun 20 '12 at 18:34
A couple decades ago, I worked on code that did the above as a "sleep()" routine. This works in single process environments where the clock as a fixed rate. (Probably not something today's developers would ever encounter.) –  Steven Burnap Jun 20 '12 at 20:11
I'm pretty sure most good compilers will optimize this out[Assuming you enabled optimizations]. Those who don't just didn't spend the time to add that feature to their optimizer. –  CodesInChaos Jun 20 '12 at 21:37
The compilers are smart, of course. But they aren't designated to think instead of a programmer who would write something like that without any goal. –  superM Jun 21 '12 at 12:00

9 Answers 9

up vote 18 down vote accepted

In general, its hard (that is, undecidable) to prove if something is a silly busy loop (that could be optimized out) or an infinite loop (that cannot be optimized out withuot changing the meaning of the program). Does the following code loop forever or does it stop?

var n = //some positive integer
while(n != 1){
   if(n % 2 == 0)
      n = n/2;
      n = 3*n+1

Because of this complexity, most programming languages give up on trying to reason too much about the program and therefore pass the responsibility of not running silly busy loops back to the programmer.

share|improve this answer
Using the normal 32bit integer types, it definitely halts ;-) –  user281377 Jun 21 '12 at 11:19
It doesn't matter if it stops. What matters is if the value of 'n' is ever used after the loop. If not then the whole loop can be optimized away. –  Jon Strayer Jun 21 '12 at 15:41
@JonStrayer: You can't optimize away an infinite loop without changing the meaning of the program. What if I had a "fireTheMissiles()" call after the infinite loop? –  hugomg Jun 21 '12 at 19:17
@NickC: The hard part is the "provably" bit. While some sorts of effectless while loops are straightfoward to optimize (and many compilers will do so), its easy to get in a slippery slope of properties that get harder and harder to prove and everyone gives up at some point. –  hugomg Jun 22 '12 at 14:13
I didn't say you could optimize away while(true) in general. But if the block has no side effects or used values you can. An infinite loop that calculates no used values and has no side effects is a bug. –  Jon Strayer Jun 22 '12 at 23:31

Get a better implementation. Many C++ compilers I know would remove much more complex code with no side effects than this.

share|improve this answer
Oh no! How will we speed up the program when our boss complains it's too slow? ;) –  FrustratedWithFormsDesigner Jun 20 '12 at 20:05
How does this answer the question??? –  Matthew Flynn Jun 21 '12 at 3:26
@MatthewFlynn: It proves that the "problem" the OP sees is based on an incorrect fact, and therefore there is no problem at all. –  DeadMG Jun 21 '12 at 3:46
@MatthewFlynn: interestingly, my answer was deleted by a mod, though saying a similar thing (granted, DeadMG was first though, but the rationale is odd :)). –  haylem Jun 21 '12 at 14:32
@DeadMG The question said nothing about C++, the example code is not C++, and some people in some places do want this to execute. –  James Jun 21 '12 at 23:31

This code may do nothing as you think it does, but what if, taking C# as example, I had overloaded the + operator.

public static int operator +(int one, int two) {/* implement crazy operation here */}

In the overload, I'd generate a frame and scale the operator to sync for 60fps.

This "useless" loop has now become a game that stops at the 100000000th frame. Not so useless heh?

Your inability to clearly define "useless code" is why the compiler can't deal with it.

share|improve this answer
Can the compiler see that the + operator is overloaded? Then we still don't have a problem. –  Jon Strayer Jun 21 '12 at 16:05
Even if the compiler didn't, the CLR can. –  MSalters Jun 22 '12 at 14:52

Commonly (and probably the only valid use for this) used in micro-controllers to control timing accurately, however most likely to be written in Assembler (or inline assembler in a C programmer) as the programmer then has absolute control over the instructions used, hence the time taken.

share|improve this answer

There's 2 things to mention here. The first is that, many compilers as DeadMG said might optimize out code like this. As you probably know, if the point of the code was to take time, then this is inaccurate and dependent on the frequency of the processor.

The second thing to point out is your mentioning of "effect-less". It might not be what you mean, but many devs (especially those who are fans of functional programming, and its associated paradigms) advocate that you should avoid side-effects almost entirely - that is to say, have no external state. Generally speaking, programming in this way requires that you return some value from every function, thus it doesn't apply to the trivial example that you posted - but does to less-trivial examples.

share|improve this answer

To create an extreme loading condition

One use of the Unix yes application, which uses a similar loop construct, is to exercise the CPU to simulate high load.

It also provides a continuous "y" output for use with responses to older versions of Unix command lines.

I realise that the yes application is providing a measurable side-effect and so would not get optimised away, but the point I'm making is that fast, tight loops serve as useful load tests.

share|improve this answer

As @BillMichell suggests in his comment, the point is to consume time, assumably to allow something else to happen. Most modern languages have a better way to do this--telling the thread or process to sleep or wait for a specified period of time. In the bad old days, that wasn't an option.

share|improve this answer

2 reasons first is that to fully remove all dead code compilers would need to solve the halting problem which is impossible and many compilers don't even try

second sometimes the programmer want a delay/busy loop there for various reasons (including simply slowing everything down so when Mr. Boss tells you to speed it up you can remove a 0 from the upper bound)

share|improve this answer
To be able to remove all dead code in all possible programs they would need to solve the halting problem. That's not necessary in the above loop. –  Jon Strayer Jun 21 '12 at 15:46

First languages have most probably nothing to do with the issue. Definitions of languages give the observable behavior and they don't consider duration as observable behavior excepted for very special purpose functions.

Thus you are speaking about implementation choice.

As a documented case, let's look at gcc.

In early gcc documentation, they stated that they purposely didn't remove empty loops as they were most probably there for a timing purpose.

In newer one, they now state they have reversed their decision as empty loops are now most often due to other optimizations (which may remove all existing content) and they warn that empty loops will be removed if gcc is able to show that they will terminate.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.