Topic: Performance

GWT Performance Talk

Dietrich Kappe, Tuesday, December 4, 2007 @ 5:30 pm

Another talk that was really more about general Ajax performance, rather than GWT performance. I've done a bit of work here myself (see chapter 9), so I'm always looking for some new tips and tricks. Joel Webber did a manful job going through the usual suspects -- fewer HTTP requests, bundle images, compress your JavaScript, perceived performance and actual performance are two different things.

Maybe the biggest bombshell was his recommendation to use innerHTML to build large DOM structures; it was an order of magnitude faster in all browsers than direct DOM manipulation. While that recommendation seems reasonable, it makes the GWT abstraction even leakier.

Some more GWT specific perf recommendations:

• Use the DeferredCommand to split long running
• Immutable resource bundles that will let you use image bundles in CSS background images.

Some quotes:

"Our JavaScript doesn't gzip quite as much as others, because our JavaScript doesn't include as much redundant crap."

"We had a hard time measuring JavaScript compilation because it takes so little time on modern computers."

"Firebug is often wrong when it comes to network timing. It has led me down a rathole several times."

"HTTP requests are the most time consuming thing you will do. DOM manipulation is next."

Technorati Tags: gwt, ajax, performance

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

The Depressing State of IE Development Tools

Dietrich Kappe, Monday, August 6, 2007 @ 5:47 am

A while back I contributed a chapter on Ajax optimization to Real-World AJAX, and as a part of that effort I did quite a bit of digging around for tools to do profiling in IE. The pickings were slim. Now whenever a new book on Ajax comes along, I take it as a point of professional interest to check out its section on profiling and optimization, and so far the lack of progress in tools for IE is depressing. What a contrast, though, between Firefox and IE: while Firefox now has a souped up FireBug and the venerable Venkman, IE's got the same old developer tool-bar, the script debugger and various HTTP proxies to debug XHR and other requests. Of course there's always Visual Studio. Blech. How many virtual machines can you run with IE6 + VS, IE7 + VS? I need a 6GB laptop to get reasonable performance, and even then I don't get profiling.

So, what are the options for profiling code in IE?

• Tito Web Studio - the old commercial standby. Gets the job done, but be prepared to fork out ~$200 per developer.
• IEWatch - new commercial kid on the block. I haven't used it yet, but it provides debugging and profiling.
• You can hand code timing functions using a simple AOP framework like Ajaxpect. That's sort of the approach taken by qooxdoo, i.e. you can instrument the entire app in this way.
• JsLex - very sweet cross-browser profiler. You deploy it as a war in an appserver and expose it through the same url as your app. On the client side it works by parsing and instrumenting your Javascript code. You can do that either through the webapp's interface or through an ant task. Not quite as simple as Firebug, but still pretty sweet. See this Ajaxian story for some screenshots.

There are a few other things on the horizon, such as AjaxView, a server-side proxy that rewrites and instruments your JavaScript as it is served up. Still experimental. I realize that the above is a potentially bigger concept than a plain old profiler, but how about starting with the simpler ideas and working our way up?

Technorati Tags: ajax, tools, profiling, javascript

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Ajaxpect: AOP for Javascript

Dietrich Kappe, Monday, July 2, 2007 @ 6:37 am

I was looking for a quick way to profile some code in IE. I didn't want to grab Tito (commercial) or JsLex (browser independent, sweet, but a bit of a hog). So I went hunting for a simple little AOP library for Javascript and came across Ajaxpect. In 58 lines of Javascript, it gives you the ability to add before, after and around advice. From the included example:

// Example business logic var thing = {     makeGreeting: function(text) {         return 'Hello ' + text + '!';     } }alert(thing.makeGreeting('world')); // Hello world!

// Advice definitions function aopizeAdvice(args) {     args[0] = 'AOP ' + args[0];     return args; } function shoutAdvice(result) {     return result.toUpperCase(); } function ciaoAdvice() {     return 'Bye-bye!'; } 

// Adding advices Ajaxpect.addBefore(thing, 'makeGreeting', aopizeAdvice); alert(thing.makeGreeting('world')); // Hello AOP world! Ajaxpect.addAfter(thing, /make*/, shoutAdvice); alert(thing.makeGreeting('world')); // HELLO AOP WORLD! var filter = function(name) { return name.indexOf('Greet') != -1 } Ajaxpect.addAround(thing, filter, ciaoAdvice); alert(thing.makeGreeting('world')); // Bye-bye!

Technorati Tags: ajax, aop, profiling

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Five Javascript Compressors Compared

Dietrich Kappe, Friday, August 11, 2006 @ 9:00 am

Without a doubt Ajax application are becomming more powerful. That also means that Javascript files are getting bigger and more complex. One solution is to use mod_gzip and mod_deflate (Apache) or HTTP compression (IIS). This means adding extra processing time both at the server and the client, however. One other way to cut down on bandwidth and memory is to compress the Javascript, after all, the browser doesn't need the nicely formated Javascript with white space and comments. You can just trim all of that out and save tons of space.

With that in mind, I decided to test out some of the better known Javascript compression algorithms. My test consisted of compressing three files: ClientEngine.js from the Echo2 framework, prototype.js from Prototype version 1.4.0, and a GWT ( Google Web Toolkit) compiled file from a small widget project. The GWT file was edited slightly to turn it from an HTML file into a Javascript file.

The compression tools tested were:

1. Memtronic's Javascript/HTML Cruncher-Compressor v1.0k - Does a straighforward whitespace/comment crunching and a more fundamental transformation, aka compression.
2. Dojo Shrinksafe - Rhino based. Supposed to be "safe."
3. Creativyst Javascript Compressor - Pretty standard whitespace/comment stripper.
4. Dean Edward's Packer - takes a little different tack, transforming and evaluation the Javascript as a string. Allows the compression of Javascript keywords, like 'function.'
5. Douglas Crockford's JSMin - Also a pretty standard whitespace/comment stripper.

The results of my test are in the table below.

The GWT file is already partially compressed, so a more fundamental transformation needs to happen in order to squeeze it some more. The Echo2 file was the largest and also was formatted for human consumption with comments, indentation, descriptive identifiers, etc., so it showed the greatest compression ratio.

Of the three "advanced" compressors, all of them had issues with prototype.js (syntax errors in the resulting code), but Dojo Shrinksafe didn't have any issues with the other two files. Packer seemed to work OK in IE6, but not in Firefox. Memtronic seemed to have problems in all three in both IE6 and Firefox.

The lesson? Test your compressed Javascript in all browser versions you plan to support (JsUnit, anyone?) or just use mod_deflate and company to handle your compression needs.

Technorati : compression, javascript, performance

• Digg
• Reddit
• del.icio.us

Comments (9)

Software Development