Shane O'Sullivan's technical blog… really ties the room together

Archive for the ‘performance’ Category

Tracking memory usage on WebOS with GnuPlot

Posted by Shane O'Sullivan on October 16, 2011

I’ve been fighting against a serious memory leak in a WebOS app I’m developing, and unfortunately the tools available for WebOS are no help whatsoever for these kinds of problems. There is a program available for WebOS called JsTop, but the data that it tracks doesn’t show that my app is using lots of memory, while at the same time the Touchpad is crashing with the infamous “Too Many Cards” error, with just one card on the screen.

So, I decided to see what I can do about it. A little fiddling with novaterm, grep, awk and GnuPlot has helped me a lot, and hopefully it can help you too.

The image above shows the percentage memory (red) and CPU (green) usage over time of the WebAppMgr process in WebOS, which is essentially where all the apps are executed.  To get a graph like this, download the following two scripts (Mac/Linux/Cygwin only): [Source]

You’ll probably have to make them executable, so do:

chmod +x
chmod +x

Then plug in your WebOS phone or TouchPad via USB, and run


and you should see a graph like the one above.  If you don’t see it, it’s likely that you don’t have GnuPlot installed, so Google how to do that for your system, it should be trivial.

For what it’s worth, I get a “Too Many Cards” error just before the process hits 60%, meaning that the other running processes are taking up the remaining ~40% of memory.

If you feel like playing around with this script and doing something else cool, let me know!

Posted in performance, WebOS | 3 Comments »

JavaScript performance tips

Posted by Shane O'Sullivan on September 28, 2011

Every now and again a question comes up at work as to which of two or more approaches to the same problem in JavaScript performs better. I’ve started using the fantastic site to document these, so I’ll append to this post whenever I add a new test. I hope you find these useful, as they are answering questions that pertain to practical JavaScript usage.

Creating a regex inside and outside a loop

Declaring variables in a loop or outside it

Using hasOwnProperty or testing with undefined and void 0

Using indexOf or substring to test the end of a string

Extend Without Foreach

Posted in Javascript, performance | 1 Comment »

Dojo gets a speed boost on IE6 and IE7

Posted by Shane O'Sullivan on August 28, 2010

My former employer, Cúram Software, was good enough to give me a couple of months to work on the performance issues that Dojo and it’s widget project Dijit have in horrible legacy browsers IE6 and IE7.  Some of the fruits of that labour have now been checked into the code base and will be included in Dojo 1.6, out in Q4 2010.

So what I/we learned from the exercise?

DynaTrace rocks!

To begin with, I can’t praise DynaTrace enough.  It’s a fantastic piece of profiling software that delves deep into Internet Explorer’s innards to find every little horrible Microsoft bug.  It can take a while to get used to, but that is just because it presents you with so much data, all of it useful, and anyone would have trouble finding a way to make it easily consumable.  Long story short, if you’re having performance issues with your site in IE, download DynaTrace.

Touching className makes IE cry

Pretty much every time you change the className property of a node, IE6 and IE7 reflow the page.  It doesn’t matter if the new value is the same as the old one, or whether or not the changed CSS class has any visual effect, IE will redraw the page, resulting in a lot of time being lost.

Dojo was changing className too often, for example in dojo.addClass, if the class being added was already present, it would still assign the changed value to className.  I put a fix for this into v1.5.  There were also many cases where Dojo would use a combination of dojo.removeClass and dojo.addClass to replace a class, which changed className twice instead of just once.  To fix this, I’ve added a new public api dojo.replaceClass, which only changes className once.

Dijit widgets often add CSS classes to the DOM nodes which they are creating after the nodes have been inserted into the document.  This is costly, and a large performance improvement can be gained by applying these classes earlier in the lifecycle, before inserting into the document.  Bill Keese (Dijit master) checked in the first of the fixes for this for the BorderContainer recently, and a strategy is being formulated for the many other widgets that can benefit from this.  This work should be completed for v1.6.

Risky but…..

A solution that we cannot use for Dojo, but which we found gave huge performance gains for my company’s application, was to figure out what CSS classes Dojo would apply to a node and write those classes out when generating the HTML.  For example, when creating a dijit.layout.BorderContainer, our HTML contains the CSS class dijitBorderContainer.  There is an inherent risk with this approach, as Dojo may change the CSS classes in a later release, but if you’re willing to accept the risk and the upgrade pain, you can get a nice performance boost this way.

Reading offsetLeft and offsetTop is costly

When your code reads the offsetLeft or offsetTop of a node, all pending changes to the DOM have to be performed first.  This can be very expensive – we saw a number of single operations taking over 500ms each!  Many Dijits were using the dojo.marginBox method to get the left, top, width and height properties of a node, when all they needed was the width and height.

To solve this, I introduced a new method, dojo._getMarginSize, a private method that just returns the width and height of a node.  This has resulted in huge gains in performance on IE6 & 7, especially when used with layout widgets like the BorderContainer.

Unexplained gaps in DynaTrace profiles

We hit a bit of a wall at one point when analysing the performance profiles, where there was a 1.5 second gap in the profile where it seemed like nothing was happening, but everything was paused with the CPU at 100%.

We eventually discovered that there is a horrible bug in IE7 where if you have a :hover style on something that is not an anchor tag, it causes the rendering engine to go crazy, get all confused, and push the CPU up to 100% for no reason at all.

The solution: don’t user :hover styles on anything other than <a> tags.  Ridiculous I know, but so is the IE7 rendering engine.

Give it a go!

So, the long and short of it is that Dojo/Dijit should now be a good bit snappier on IE6 and 7.  With our application we got the load time for a huge application down from 20 seconds to 5 seconds using these techniques, making IE7 far, far more usable.  Of course it just flies on any other browser, even IE8 which, all credit to MS for once, is far less buggy than the earlier incarnations.

So feel free to try out the Dojo nightlies, you should find them to be a good bit more responsive in IE6 and 7 than just a few days ago, and now that we have learned some important lessons, Dojo will be even faster for v1.6.

Posted in Ajax, dijit, Dojo, Javascript, open source, performance, Technical | 10 Comments »

Huge performance increase on IE for Dojo 1.4

Posted by Shane O'Sullivan on December 15, 2009

Performance charts have just been published for the newly released Dojo v1.4, and the focus that the team put on improving Internet Explorer performance has really paid off.

On IE6, IE7 and IE8 there are speed improvements across the board of between 25% and 40%.  That’s huge.

See the charts (courtesy of Pete Higgins) here –

Run the tests yourself here –

Posted in Ajax, Dojo, Javascript, open source, performance, Technical | Leave a Comment »

Dojo event performance tip

Posted by Shane O'Sullivan on August 23, 2007

When working with the Dojo Ajax Toolkit and using it’s dojo.event package to listen to DOM and custom events, the two most common approaches are:

  1. Listen for an event (or function call) to be triggered on an object, and when it is to run a custom function, e.g.
    var alertFn = function() {alert(“widget is showing”);};
    dojo.event.connect(myWidget, “onShow”, alertFn);
  2. This basically says that when the “onShow” function is called on some widget, called myWidget, run a function that does a simple alert. Of course you can do whatever you like inside this function.

  3. Listen for an event (or function call) to be triggered on an object, and when it is to run a custom function defined in the scope of an object, e.g.
    var myObj = {
    alertFn: function() {alert(“widget is showing”);}
    dojo.event.connect(myWidget, “onShow”,myObj, “alertFn”);

    This is saying that I have an object called “myObj“, which has a function called “alertFn“, and when the “onShow” method on “myWidget” is called, call the “alertFn” function on “myObj“.

I’ve found that when working with Dojo version 0.4.2 and 0.4.3, using the second approach is far far quicker. It turns out that internally, if you simply pass an anonymous function to Dojo, it will add that function to an internal structure and do a brute force search on that internal structure to make sure that this function is unique. This can result in a very significant performance hit – I’ve seen it take up over 50% of the startup time of a page on one of our more JavaScript heavy applications.

So, the conclusion is that if you are dojo.event.connect, which is one of the most useful functions in the toolkit, make sure to use four arguments to the function (approach #2 above), rather than just three (approach #1 above). If necessary, place a simple wrapper around the function as I have shown.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt

Posted in Ajax, Dojo, dojo.event, Javascript, open source, performance, Technical | Leave a Comment »

%d bloggers like this: