29

setInterval()

Calls a function or executes a code snippet repeatedly, with a fixed time delay between each call to that function.

while()

Creates a loop that executes a specified statement as long as the test condition evaluates to true. The condition is evaluated before executing the statement.

If I use while(true) to execute a specific statement, my browser either crashes(Firefox), lags(Opera), or the statement won't be executed(Chrome), but if I used setInterval() with a fixed time of 0 seconds, everything works perfectly, even though its only 0 seconds, and while(true) can't logically be faster than 0 seconds, but why does this happen?

while() example:

<!DOCTYPE html>
<html>
    <body>
        <div id="counter"></div>
        <script>
            var i = 0;
            while (true)
            {
                document.getElementById("counter").innerHTML += i++; 
            }
        </script>
    </body>
</html>

setInterval() example:

<!DOCTYPE html>
<html>
    <body>
        <div id="counter"></div>
        <script>
            var i = 0;
            setInterval(function() { counter() }, 0);
            function counter()
            {
               document.getElementById("counter").innerHTML += i++;
            }
        </script>
    </body>
</html>
David G
  • 94,763
  • 41
  • 167
  • 253
Ali Bassam
  • 9,691
  • 23
  • 67
  • 117

5 Answers5

24

There is a large difference which involves locking. The first approach, the while loop is going to lock up the user's cpu because it runs forever without stopping and will take up 100% of the processor. setInterval actually has a minimum amount which is implicit, and depends on the browser. I believe it is around 10ms. So, your setInterval is actually only running for a millisecond or so doing that simple update, once every 10ms. This is harsh on the processor, but will not require 100% of the processor and can be mitigated with task management by the operating system.

Travis J
  • 81,153
  • 41
  • 202
  • 273
16

  • while(1) generates an infinite loop, that is, JavaScript will simply run forever and never give control back to the browser, which therefor freezes, because it is unable to to anything else ever again (until the script is killed).

  • setTimeout(func, 0) behaves differently in the sense that after it executes, control is given back to the browser, which may then decide what to do after. Setting 0ms in setTimeout does not guarantee that the JavaScript code is run directly after it stops. With the 0ms parameter you merely tell the browser that you'd like the code to run directly after it stops, but the browser is free to do something else entirely before actually doing so.

fresskoma
  • 25,481
  • 10
  • 85
  • 128
14

Javascript in browsers is single threaded and event driven. No two things run concurrently, ever, and the event loop is king. If your JS never gives up control of the single thread (by ending a function), then nothing else can use the thread. The same thread handles JS and DOM, so the user can't even scroll or click on anything if your JS is hogging the thread.

setInterval (or indeed setTimeout) with a delay of 0 (milliseconds, not seconds) only means add this function to the event queue after the given delay, there is no guarantee the function will be executed at that exact time.

EDIT : actually, web workers can run JS at the same time as the main browser thread, but they don't see any of the same memory / can't access the DOM, so the points / assumptions above still hold, sort of... If you want to get into Web workers, you'll want a pretty good understanding of JS / functional programming.

EDIT (again) : Why do you want to loop forever? If you are polling (only reason I could think of), please don't do that. There's almost always a better way, especially in JS. The functional way, is to define the function you want executed when an event occurs (the thing you were polling for), and then attach that function to the event (how you do this depends on the event).

Frances McMullin
  • 5,516
  • 2
  • 18
  • 19
  • 1
    Nit: I added "in browsers". The ECMAScript specification does not exclusively preclude threading .. –  Feb 12 '13 at 19:57
  • the "add event to queue after the given delay" finally made me understand. this should be the best answer – drakonli Sep 29 '20 at 08:15
5

while(true) will block any execution until the conditional loop is finished, which we already know will never happen. (Chrome)

setInterval tells the environment to execute arbitrary code every x milliseconds, it wont block your browser because the "scheduler" has still the control.

Adrian Salazar
  • 5,279
  • 34
  • 51
  • 1
    Oh, it *will* stop executing .. either when the browser tells me the script is unresponsive and asks me if I want to stop it, or I Force Close the offending program :D –  Feb 12 '13 at 19:56
  • Yeah, if a superior-power makes intervention... of course! – Adrian Salazar Feb 12 '13 at 19:58
1

Do you have a particular reason for using a never-ending loop, and even, manipulating the DOM with every each step?

If you use the while loop it'll most likely to lock the browser and client completely, also causing a possible CPU over-load if not terminated in a way.

The loop while tries to finish it's work in the most possible least microseconds. So it may even try to execute a million steps in a possible second, and maybe even more, in this case it depends on the client. However, at such speed updating the DOM wouldn't be possible.

In the case for setInterval, it's quite different from while loop, in fact, it's more appropriate to call it a function repeater. It repeats the given function after the given time is passed. So even if the time is 0, it has a step where it checks if the waiting time has passed now, and should the next repeat be run.

So you may consider while loop more instant than of 0 seconds delay.

ASertacAkkaya
  • 651
  • 6
  • 16
  • I do, i need to run real time alerts for values that keep changing, check alerts, run again , run again and go infinitely – PirateApp Oct 11 '18 at 14:18