setTimeout becomes very slow

I have written a short javascript program which draws an array of orbits, creating one large circle. It uses setTimeout heavily.

The program runs correctly, but becomes increasingly slower as it runs. I have no idea why. The url is

http://www.geocities.com/finewebsit...ularGroup3.html

My hat's off to anyone who can get this program running without the slowdown.

I have tried many, many things to fix this and none of them worked. It's a very short program, so if you think you have the solution, why not try it yourself before posting it here.

Note that all the code after the closing html tag is added on by geocities.
Note also that the same problem occurred when I ran it locally on my machine before I uploaded it to geocities.

If i was you I'd echo the value that increases the timeout value - I would think that's where your problem lies - it is probably being increased incorrectly.

Note for others - your browser will almost come to a halt when viewing the page.... my Moz FB did anyway.

Thank you for your reply.

I don't think there is a problem. The values are "blue", 20, etc. Nothing wrong with that.

More food for thought: if I set the display to "none" (and put in a window.status statement to ensure that the program continues running), then the delay disappears!

I'm beginning to think that the browser simply collapses from the strain of putting up 7,000 objects through setTimeout.

Um, yeah, 7,000 objects can a browser screw.

On the other hand, it's not the objects in and of themselves, because if I set the style.display to "none", then the slowdown disappears! So it's more subtle, methinks.

Maybe it's the rendering of the objects, which would be done client-side. When the display is set to none, the objects don't have to be rendered and so there's not as much local memory dedicated to displaying the page.

Could you clarify what "rendering" means?

Thank you.

I'm no expert on the ways browsers work, but what I'm proposing is that if a browser actually has to render (draw) an object on the screen, it probably takes longer than if the browser just has to keep track of the fact that the object exists. So if you're tracking 7000 objects but not drawing them, there's less load on the browser and thus less of a hit on the memory. Setting the display property to "none" prevents the browser from having to draw the objects. This would seem to account for why the script runs without taxing the browser if you don't draw the objects.

It might be interesting to run some tests. For example, add a modulus in your loop that sets the display to inline (or whatever) for every thousandth iteration. Then for every hundredth. Then for every tenth. Then for every fifth. I'll bet each of these tests will become progressively slower because each one is having to render more objects. Just a theory.

Just thought of another way you can monitor the speed. Within your loop, add "window.status=batchNumber;" so that you can watch what iteration you're on.

I did this, set the display to none (across the board) and noticed that the script screams through the first 70 or 80 iterations (as opposed to slowing way down by 30 or 40 when displaying the arcs) and then begins to slow down gradually to a crawl. This would seem to indicate that while the rendering does hit the browser harder than when you don't render the arcs, this script's destined to bomb simply by virtue of the size of its loop and (presumably) tracking times, etc., for each iteration.

Interesting.

I too tried setting the display to none and using window.status to monitor progress, and there was no slowdown whatsoever.

I got a very nice solution in another forum: increase the setTimeout from 1 to 200. Naturally, the program is considerably slower, but its speed remains constant throughout. (Tortoise and hare?) I also decreased the number of objects from 7000 to 5000. Combined, the program completes in under 2 minutes.

Excellent. Thanks for the followup.