lonetechie.com

I’ve come to realize while IE 7 is no less than a landslide improvement over IE 6, it is still IE. While IE alone in the market appeared to be a superior product, compared to the likes of firefox it is simply inferior. Firefox script interpreter is all around faster, in my experience it is not just 2-5x faster, it can be 100x for some operations. Crazy right? I’ve been pushing the envelope with an ajax/dojo based site I’ve spent a large amount of time on. To be blunt there is more than one occasion during the development process I have had to rewrite code to accomadate the script execution of IE 7. Looking back most of the time the script was poorly thought out set of operations that needed to be rewritten anyway.

My last road block however was a particular chunk of JSON data that was packaged up base64 encoded then sent off to the server via the dojo xhrpost method. I really was scratching my head whenever I was in IE and got up to a 3-10 second delay while sending this data to the server. While in Firefox and Safari there was none. After a period of a few hours I narrowed the delay to my base64 encoding script running on the client side causing the delay. It didn’t take long start finding that IE is incredibly inefficient as string concatenation. The solution is simple.  Implement a string buffer.  I have provided some snippets along with the corrected JS file for viewing.

// addresses some speed issues with IE 
function StringBuffer()
{
this.buffer = [];
}
 
StringBuffer.prototype.append = function append(string) {
this.buffer.push(string);
return this;
};
 
StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
};
 
// end buffer
 
function encodeBase64(str){
 
...
 
var buf = new StringBuffer(); // new buffer code
 
...
 
//result += (base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]);
 
buf.append(base64Chars [(( inBuffer[0] << 4 ) & 0x30) | (inBuffer[1] >> 4) ]);
 
...
 
}

Source for the entire base64 file here:
base64.js

I have ventured deep into the land of asp.net the past few months.  Luckily the the blogsphere keeps me on track.  Every day or so I run into a nagging issue with asp.net or something I can’t quite accomplish.  I have been nearing the end of my project and have simply had a big which I could not fix.  It seems asp.net will fire an error when ANY file is missing on an asp.net webpage.  This is incredibly difficult to diagnose since the error does not contain the file that is missing!  See below for an example

MESSAGE: File does not exist.
SOURCE: System.Web
FORM:
QUERYSTRING: 695777780
TARGETSITE: Void ProcessRequestInternal(System.Web.HttpContext)
STACKTRACE: at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context)…

Catching the error is accomplished by hooking into the Application_Error event typically in the global.asax

void application_Error(object sender, EventArgs e)
{

}

K# offered a great post on just how he went about solving this issue. Basically setting a breakpoint at the above section of code to see the error when it happens. That isn’t quite enough, you’ll notice visually studio even in the watched variables has nothing that leads to the missing file. If you add a watch to ((HttpApplication)sender).Context.Request you will quickly see the exact file causing the error message.

My ultimate solution was to add the ((HttpApplication)sender).Context.Request.FilePath in all my global error logging so the file that is missing is always included in the error message.