Entries tagged ‘xopus’

Over at the Xopus blog, I’m discussing what I spent my summer on: a DHTML caret! Go read it and see the demo!

I had to write a depth-first tree iterator recently – at Xopus of course – and I wondered about the call stack size. Here is the test, and the results:

• Safari 2.04: 100
• Firefox 2.0.0.6: 1001
• Internet Explorer 7: 1789
• Opera 9.22: 3340

Safari surprises me, it’s just 10% of Firefox! Opera stands out quite clearly as well.

At Xopus we develop a pretty big (~50k lines) JavaScript application to edit XML documents through a WYSIWYG interface. With such a large application there’s a large risk of memory leaks. Indeed, this is what we’ve been experiencing in Internet Explorer 6. We’ve also seen a decrease in performance as memory usage increased. These leaks, however, do not occur in Internet Explorer 7. And, as of just 10 days ago, they no longer occur in IE6 on Windows XP.

On June 12th, Microsoft released security update MS07-033. Included in this update is the following:

General distribution release (GDR) fixes
A memory leak occurs in Internet Explorer 6 when you view a Web page that uses JScript scripting on a Windows XP-based computer (KB929874)

And indeed, IE 6 on Windows XP no longer leaks memory, nor performance. This is great news for all JavaScript hackers, there’s no need to worry about memory leaks anymore!

The one cave-at is that this fix is only available for Windows XP. For Xopus this means we’ll still have to fix the leaks, since some of our clients are still running Windows 2000. Users who haven’t installed the latest security updates will also experience memory leaks in IE 6. In the end though, Microsoft fixed the memory leak issues in Internet Explorer, and I’m thankful for that.

Yesterday I was hunting down an Internet Explorer memory leak at the office. I started with disabling all events which might leak, and then began to check them one by one. With a stroke of luck the first event I checked caused the biggest leak, which was several megabytes on each page load. The event wasn’t to blame, though.

In fact the real bug was something much harder to grasp than the closure-induced leak. And, since I couldn’t find it described elsewhere, I’ve decided to coin it the Externally Declared Global Variable Leak. It has been confirmed in IE6 and IE7.

Here’s the problem in a nutshell:

• When you create circular references between window objects
• And declare global variables (someWindow.globalVariable) on window object A, from window object B (or vice versa)
• These variables will leak
• Even if they are not referenced

There are a number of possible solutions:

• Prevent or clear the circular references
• Declare the global variables inside the window object
• Use eval() to declare the variables from another window
• Remove the variables

I’ve created three testcases, one leaking, another one leaking, and a non leaking one. For fun I’ve added a ~ 20 MB object to the tests, so the leaking will be rather obvious.

As you can see in the tests the leak occurs if the global variable is declared in the main window. Declaring the circular reference variable – which is global as well – in the iframe window has no effect. This leads me to believe the JScript engine thinks the leaking variables are still referenced, because they were declared by another window object.

So, yet another thing to look out for when developing for IE. Happy leak hunting!