Cleaning up unresponsive script errors

wes — Fri, 03 Jul 2009 18:58:13 +0000

I recently worked on improving performance in a labor scheduling application. The app was originally designed to load all the employees at one time in one large chunk, processing and stuffing the data into various places as needed on startup. This all worked fairly well on average stores with 50-100 employee records until we discovered several stores with 100+ employee records which caused the browser to display an unresponsive script warning due to the rather heavy pre-processing algorithms.

After scouring the web for clues to help me get rid of this warning without changing settings on the browser, I found out that the only way to avoid these warnings was through a pseudo-threading pattern using setTimeout¹².

One of the patterns I came up with to process a sequence of commands (such as adding records to a store) one at a time while still allowing the browser time to refresh and process other commands:

var chainedTasks = [
   function() {
      console.log('first set of tasks');
   },
   function() {
      console.log('second set of tasks');
   },
   function() {
      console.log('third set of tasks');
   }
];

var currentTaskNum = 0;
var isExecuting = false;
var emptask = {var emptask = {
	scope: this,
	interval: 100,
	run: function(){
		if(currentTaskNum > chainedTasks.length) {
			Ext.TaskMgr.stop(emptask);
		}

		if (!threadIsRunning) {
			threadIsRunning = true;
			if (typeof chainedTasks[currentTaskNum] === 'function') {
				chainedTasks[currentTaskNum](currentTaskNum);
			}
			currentTaskNum++;
			threadIsRunning = false;
		}
	}
};
Ext.TaskMgr.start(emptask);

Multi-threading in Web 2.0

wes — Wed, 10 Jun 2009 19:21:22 +0000

I’ve been tasked with speeding up a web 2.0 application based on ExtJS 2.2.0 that contains several routines that take up quite a bit of time and, because IE6′s javascript processing engine is less than stellar¹, I needed to find a way to “speed things up”.

Enter Ext.TaskMgr, a helpful ExtJS object that is essentially a glorified setTimeout implementation that allows us to run tasks that don’t block execution. This means we can set our more expensive blocks of code to run later but return control back to the user in the meantime. It’s not true multi-threading, but it does allow us to make the user interface a lot more responsive and in an age when users think 5 seconds is an eternity, perception is everything.

In other words, it sucks pretty bad.

Werx Limited » performance

Cleaning up unresponsive script errors

Multi-threading in Web 2.0