Geek Answers Handbook

Is there something inherently wrong with using setTimeout to simulate a parallel action?

When users of this application make changes to the fields, a large number of changes must occur in other fields. As a rule, even with optimized scripts, the browser blocks user input for 1 second in IE. To stop this, I do this:

var i = 100; GetTextInputs().filter('[' + name + ']').each(function() { setTimeout("DoWork('" + this.id + "', '" + v + "', '" + name + "');", i); i += 25; });

I think it's hacks, but it works great.

  • Can anything go wrong with this method?
  • Alternatively, is there a better way?
+4
source share
3 answers

One thing that can go horribly wrong is that too many high-frequency timers can [ironically] make ui lethargic / unresponsive. From http://googlecode.blogspot.com/2009/07/gmail-for-mobile-html5-series-using.html :

With low-frequency timers - timers with a delay of one second or more - we could create many timers without significantly reducing performance on either device. Even with 100 timers planned, our application was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was enough to make our interface a bit sluggish.

+3
source

Right now, I don’t think you really have a lot of choices.

I did not check if your function works, but using setTimeout and splitting the work into small pieces is probably the way to go.


However, in the future you can use Web Workers ; quote from Mozilla webpage :

Workers provide simple tools for Internet content to run scripts in the background streams. After creation, the worker can send messages to the spawning task; send messages to the event handler specified by the creator.

Workflow can perform tasks without user interface. In addition, they can perform I / O using XMLHttpRequest (although responseXML and channel attributes are always null).

AND:

One of the workers is useful to allow your code to perform intensive calculations without blocking the user interface thread.

Those are already available in Firefox 3.5, and I think they are also provided by Google Gears, but they are not yet available, so you probably shouldn't use them before after a couple of years, at least for the application used "anyone": - (

+3
source

To work better with the user, I use setTimeout a lot, so working in the background can happen as much as possible.

On Windows, it looks like everything is working on the main event flow. It is more effort to make the application disconnect from this thread, but in the end the user will have a better experience.

The only thing that may go wrong is that if you have a variable change before it is actually used in setTimeout, the action may be different.

Thus, you can at least know about it if you see strange behavior. Ideally, your design should not allow, but it can happen.

+1
source

More articles:


All Articles