Whats faster in Javascript a bunch of small setInterval loops, or one big one?

Question

Just wondering if its worth it to make a monolithic loop function or just add loops were they're needed.

The big loop option would just be a loop of callbacks that are added dynamically with an add function.

adding a function would look like this

setLoop(function(){
    alert('hahaha! I\'m a really annoying loop that bugs you every tenth of a second');
});

setLoop would add the function to the monolithic loop.

so is the is worth anything in performance or should I just stick to lots of little loops using setInterval?

heres the game

http://thinktankdesign.ca/metropolis/

and all of its libraries

http://thinktankdesign.ca/metropolis/scripts/base.js

http://thinktankdesign.ca/metropolis/scripts/menu.js

http://thinktankdesign.ca/metropolis/scripts/grid.js

http://thinktankdesign.ca/metropolis/scripts/cursor.js

http://thinktankdesign.ca/metropolis/scripts/game_logic/controls.js

http://thinktankdesign.ca/metropolis/scripts/game_logic/automata.js

if I stick to individual loops there will be thousands of them because of the number of animation loops.

The game is a tower builder and complicated things like elevators and cars/peds. Not to mention loops for the automata, controlling events such as VIPs and fires and such. When functional (a year or two) it will be a lot like Sim Tower but iso-metric instead of a side scroller.

Answer 1

I would imagine that you can just use setInterval, keeping the individual loops with control over each one is going to give you better flexibility, unless EVERY single item needs to be queued, but even at that point I don't see where you would get a performance improvement from this that would matter.

Answer 2

Having them all scheduled separately means that things can happen (like processing user interaction events, et cetera) in between some of the sub-tasks occurring and others. With one big monolithic loop, each cycle of the loop will execute everything on that cycle before returning control back to user input. Thus, if you're truly doing a lot of things it's probably better to schedule them independently to allow the browser to be "smarter" about what to do when.

The exception would be if you actually intend/require that all of the things happening in the same "cycle" occur without offset from one another, in which case the "big loop" approach would be required to guarantee they all trigger at the exact same time (or at least, as close together as execution time permits).

Answer 3

Your question is impossible to answer correctly without sufficient details:

• How big is your monolithic loop?
• How many small loops do you wish to add?
• How small are those small loops?
• What are you attempting to accomplish with your loops?
• Will the small loops interact, such as altering the relationship of variables or the value of closures?
• Would there be any expectation for loop redundancy to catch missing otherwise escaped by logic consideration?

Without sufficient details every answer is correct, thereby rendering your question pointless.

Answer 4

For something like what you wish to accomplish with a game, where there is an expectation of continual interaction, you will require a degree of loop nesting between monolithic loops and smaller loops contained therein. The power of JavaScript is that its lambda feature allows closure, which I suggest you define in your monolithic loop and alter in the contained smaller loops.

You will encounter two problems in this approach:
* Potentials for namespace collision amongst variables in a monolithic loop once the loop becomes vast and variables become numerous. You must manage your named variables wisely.
* Potential for unintended logical interaction. The very power and nature of closure is a downward inheritance that provides a definable containment and private black boxes that operate upon the namespace of that containment. This implies that logical interaction upon a named variable in a containment may provide unexpected outcomes to other consuming private black boxes that was otherwise not considered, which is a logical disengagement between two smaller functions contained by a larger.

I have an example of such a suggestion in the tab_level function of markup_beauty.js. This is the most complicated logic I have written so far. I do mean to reexamine it for inefficiency, but the logical interaction of contained functions upon closure is not something that is so easily visible to change without consequence. Despite the daunting complication of the logical approach the result is powerful and efficient.

The biggest difference between this tab_level function and your code is that tab_level is mostly sequential and is executed only once. Your monolithic code will likely be called to execute many times and may itself become a function of closure or be called upon to alter closures, which is another degree of complexity to manage.

You can find my code example at:
http://mailmarkup.org/prettydiff/markup_beauty.js

You can see it operate using the beautify and markup options on the Pretty Diff tool:
http://mailmarkup.org/prettydiff/prettydiff.html