Comments on: Biggest AJAX problem

By: Robbie MacKay

Robbie MacKay — Tue, 21 Aug 2007 23:22:37 +0000

I get some bad cases of this. I run a plugin in firefox that restores my session each time I start the browser again. This becomes somewhat like not closing your browsers for weeks on end and when I keep tabs with AJAX apps open in them running that long them memory use is huge!

By: 7blfrsglg

7blfrsglg — Thu, 17 Aug 2006 21:01:43 +0000

hdv2pvs7ish5

By: Ryan Gahl

Ryan Gahl — Thu, 27 Jul 2006 14:23:48 +0000

Mark, sorry so late in replying to that last Q… I don’t think that will work, bud. I believe Event.stopObserving (also meaning the underlying DOM2 event model) requires a handle (or pointer) to the same function as the observe method (same memory address) to work correctly. Remember bind() and bindAsEventListener() return closures (anonymous functions), so you’d be passing in a newly created and different function (meaning different memory address) into the stopObserving method than you did to the observe method. I believe your method would work if you were passing in globally scoped, static function names. As with anything, try it and analyze the results to get an understanding of what’s going on under the covers :-).

By: Mark Sergienko

Mark Sergienko — Wed, 26 Jul 2006 15:38:27 +0000

Ryan,
hehe, nice job buddy.
I’ll write off on results..
And one more question
If you do like
Event.observe(“element”, “click”, this.myhandler.bindAsEventListener(this));
and then
Event.stopObserving(“element”, “click”, this.myhandler.bindAsEventListener(this));
Does it make a huge difference without saving event handlers and then reseting them?

Thanks again.

By: Ryan Gahl

Ryan Gahl — Wed, 26 Jul 2006 14:40:57 +0000

Mark, did you notice I wrote that article :-)

By: Mark Sergienko

Mark Sergienko — Tue, 25 Jul 2006 23:19:42 +0000

Ryan,
Thanks alot, i also found an article on that, and almost refined all of my code by the time,
http://www.archivesat.com/Rails_spinoffs/thread392813.htm explains the pattern,
so I’m going to delete references as well, and so far can keep FF memory on level, though IE still have some glitches. (Mainly i think because the way i implemented Google Maps Api)

Thanks for explanation again

By: Personal Interactive

Personal Interactive — Tue, 25 Jul 2006 20:33:29 +0000

I actually agree with you on your final point

By: Ryan Gahl

Ryan Gahl — Tue, 25 Jul 2006 20:20:47 +0000

Mark,
1) Using prototype as the example, and assuming “this” is an object representing your component/control/widget… notice that you should always create a handle to your event handling functions, so you can properly dispose of them using Event.stopObserving (and then remember to set the handle to null to remove all references). You can dispose of the event handlers and DOM references before you make the AJAX call, which must be a synchronous operation to be reliable, OR you can implement a DOM reference abstraction layer and pass the cleanup process to an asynchronous garbage collector object. The latter is better overall for performance of the app, but the former is easier to implement.
this.someEventHandler = this.doSomething.bindAsEventHandler(this); Event.observe($('someElement'), "click", this.someEventHandler);


//..and then later in the dispose method, either before the call which would result in this DOM fragment being over-written, or asynchronously via the DOM referencing abstraction/GC layer...

Event.stopObserving($('someElement'), "click", this.someEventHandler); this.someEventHandler = null;

By: Mark Sergienko

Mark Sergienko — Tue, 25 Jul 2006 20:08:04 +0000

Hi,
could someone make it clear
1) Do you need to unset events binded with Event.observe() (prototype.js) Once the corresponding piece is refreshed with ajax call?
2) What is cross-browser way to unload iframes? (and check if they’re loaded)

Thanks in advance

By: Remus Stratulat

Remus Stratulat — Tue, 25 Jul 2006 19:52:59 +0000

@Nick: I am primarily a Java developer. The Java GC does a very good job but even it can not solve all the problems. A good developer or a good architect should not overlook this problem any more.
No matter how good a GC will become there is a boundary that it will not cross and that boundary is cleaning objects that you are using. Defining that boundary is the biggest challenge a VM designer must tackle.
When the browser closes a page the line between used objects and unused ones is simple and clear. When the page resides in a browser for a longer period of time the GC may have a hard time in defining the used and unused references. If the developer does not take the necessary precautions in cleaning after himself the GC will not be able to perform its job.

By: Ryan Gahl

Ryan Gahl — Tue, 25 Jul 2006 19:04:55 +0000

@Kevin: Interesting, I honestly fell by a very similar technique by my own accord (I swear), with DOM referencing and cleanup across incremental partial page updates (via componentized MVC model) abstracted, and a global GC system.

@Sam: The answer is yes and yes. Yes, much of this stuff is considered proprietary to those who have discovered it, packaged it, and are trying to sell it, and yes, it’s all part and parcel to the learning curve of this new frontier. As you move through what is possible, you start running into problems. Problems are nothing more than opportunities to find novel solutions. If you are like some, once you find those novel solutions, you see dollar signs :-). It’s not about hiding things from people on purpose to oppress them though, it’s about timing and opportunity.

By: Sam Foster

Sam Foster — Tue, 25 Jul 2006 17:48:15 +0000

@Kevin: that’s interesting. I’d read about your 2 DOM approach before, but hadn’t really understood it in this context. This is the kind of thing I’m fishing for: real tried-and-tested patterns that address the core problem. The event cache is another – implemented in Dojo and Prototype among others. And higher level widgets are another – which provide a consistent interface which includes a destroy method that can get called automatically or as necessary to re-draw/re-purpose the screen. What else is out there?

My impression for the last year or so has been that a lot of work has gone into getting folks started with ajax, but much of the work that ensures success is still behind closed doors. Is this really critical competitive advantage that is being deliberately withheld? Or is it simply that most of us are still in early development phases and finding this stuff out as we go along.

As we each move from the general to the specific in our development, its understood that a lot of the lessons learned are exclusive to the particular application we’re working on. But many are not. I’m looking for good accounts of the end-game. The postings around the Yahoo Homepage change / @media presentation were valuable in providing candid information on the problems that team faced and how they solved them. Performance and memory management are bugbears that we all face. Are there any more good resources out there that address these issues?

By: Nick Husher

Nick Husher — Tue, 25 Jul 2006 17:44:02 +0000

Forgive me for being a noob, but what exact cases are there where memory isn’t being deallocated properly? Previous comments allude to DOM nodes that are not in the document tree not deallocating when the fall out of scope. Is this really the case? If so, isn’t this primarily an issue with the browser-specific implementations of the JS GC?

In any case, it doesn’t appear that there’s an easy way of tracking such a thing with modern JS debugging tools…

By: Kevin Hakman

Kevin Hakman — Tue, 25 Jul 2006 16:44:26 +0000

Here at TIBCO in the TIBCO General Interface AJAX RIA toolkit, we addressed the memory issue for AJAX back in 2001. The solution we found was to implement an abstration layer for the native DOM, managed by a client-side controller in a MVC paradigm. Thus adding and removing from the higher level DOM, managed through the controller enabled the controller to manage clean up of objects and memory in a more predictable and manageable way. Keep in mind this technique was used to support Web applications that look and perform like desktop GUIs as opposed to slight enhancements here and there in the context of HTML pages (e.g. Client/SOA ajax as opposed to Enriched HTML page ajax). This “2 DOM” approach as early as 2001 was suffucuent to power chemogenomic drug disovery solutions deployed to the USFDA and major pharma companies. That solutions was very data instensive and loaded/unloaded about 180 various application modules over lengthy (multiple hour) sessions. There’s a recording including discussion about that solution here: http://www2.sys-con.com/webinararchive.cfm?registered=on&pid=61

By: Ryan Gahl

Ryan Gahl — Tue, 25 Jul 2006 15:55:04 +0000

@Peter: Even very good garbage collected languages will have cases where resources are being accessed outside of the managed environment, in which case there is no alternative other than the developer writing custom finalizers (dispose methods) on their objects, and ensuring that they get called when appropraite. For js UI components this amounts to setting DOM element references and event handler references to null. One approach, as I’ve alluded to, is creating a custom AJAX control garbage collector that handles this process in the background. Once that system is built into the application architecture, it makes it slightly easier for the developers; they just write the finalizer methods for each component and the system handles when those methods get called.

@Alexandru: Sorry, wasn’t implying you didn’t know good programming practices :-)… agreed that there are oh-too-many designers/amateurs trying to handle application development with very little concern for architecture. Even though much of the application has potentially migrated to the client, this does not mean we can do away with the developers, it just means the developers need to learn this environment, and let the designers do what they do best, design.

By: Remus Stratulat

Remus Stratulat — Tue, 25 Jul 2006 15:47:06 +0000

Yes, JavaScript is a GC language. And yes, some times the browser GC or JSVM does not do a good job in cleaning the memory. I found a reference about it in this article: http://www.bazon.net/mishoo/home.epl?NEWS_ID=1281

However, the job of a JavaScript programmer has become more difficult in the AJAX era and that is the focus of my article. In the old days a JavaScript programmer was comfortable enough in being sloppy with the objects he was creating as the browser was cleaning everything up when the page was reloaded. When you are developing a single page AJAX application everything is loaded and created in the same scope. If the programmer does not take care to â€œnullâ€ everything that he has created when he no longer needs it then you have a big problem. Not to mention about unregistering all the listeners from all the events. It is very easy to get lost in the referencing scheme. So unfortunately the JavaScript developers arenâ€™t doing a good job of garbage collection.

There are 8 millions html developers and each one of them will think sooner or later to get his hand dirty with some AJAX. They will pull some content from the server and create a bunch of objects and register events to them. After that they will pull some more content from server and do the same thing on the same page. What do you think has happened with the objects he first created? They will continue to linger in a â€œno objects landâ€ inside the JSVM, ghostsâ€¦ memory leaks.

By: Alexandru COSTIN

Alexandru COSTIN — Tue, 25 Jul 2006 15:31:37 +0000

Hi Ryan,
I know about sound programming practices, but I’m in the web development business (selling tools), and I can assure you that there are very few developers and senior developers there, while there are millions of newbies that want to do Ajax and that are actually deploying live websites

As for the reloading experience, we’ve analyzed in depth the Gmail experience when doing Ajax navigation. While we suppose only data in exchanged with the server, the page refresh process is the following:
Change cursor to “waiting”Show Red Loading Label in the upper rightShow white pageShow new page
I presume that the experience for the user was ok as actually nobody saw this :)

And for managing the states, we’re trying to solve the application state problem in our framework, solving this developer problems automatically. But indeed, it was a very, very difficult problem to solve.

Let’s just wait and see how good web developers/newbies will get in learning advanced programming techniques, or whether the browsers will get better in improving the JS GC

Alexandru

By: Bogdan Ripa

Bogdan Ripa — Tue, 25 Jul 2006 15:28:14 +0000

One of the biggest problems I see is that there is no (reasonable) way to removeEventListeners in JavaScript.

Imagine some DOM elements that have listeners attached. Then, the DOM elements are removed, but the events remain attached…

I had this kind of problems when implementing a simple tooltip engine, where after removing the target elements from the DOM, the tooltip elements were still there, and no GC engine would remove those…

So at the end, it’s a question of good programming and a good GC.

Bogdan

By: Peter Harkins

Peter Harkins — Tue, 25 Jul 2006 15:01:42 +0000

The moral of the story here is not “Javascript developers aren’t doing a good job of garbage collection”, it’s “Browser developers aren’t doing a godo job of garbage collection”.

There’s no malloc in JS, it’s supposed to be a gc language. These are interpreter bugs that JS coders are having to work around.

By: Ryan Gahl

Ryan Gahl — Tue, 25 Jul 2006 14:49:53 +0000

Sam, the best way to prevent leaks is look at your architecture as a whole. The best “tool” is good application design from the bottom up. If you are poring through files that are filled with markup, server code, and javascript throughout, looking for all the individual places where there might be a circular reference or potential leak, then yes, you can never really be sure you got them all. If your design is clean, with good separation of concerns, and controls are componentized then memory management will fall right in.