Skip to Content
author's profile photo Former Member
Former Member

MI performance deterioration because of IE and HTMLB

Hi All,

We've developed a mobile application (currently running MI2.1) for one of our customers.

The application runs on a laptop and uses HTMLB for presentation.

When used intensively the performance of the application droppes and Javascript errors start popping up.

It seems that the HTMLB and IE combination is the bottleneck. HTMLB generates a lot of javascript (some deferred) with a lot of eventhandlers.

Garbagecollection is a problem in this case.

The IE problem is explained in:

http://www.bazon.net/mishoo/articles.epl?art_id=824

It apprears to me that we are not the first ones to stumble across this problem.

Anyone has a solution?

The 'normal' workaround would be to store all the object names when a page is created and nullify the objects on page unload. Because of the dynamic tag generation of HTMLB this is not possible.

Any help would be appreciated.

Thanks in advance!

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on May 17, 2005 at 12:28 PM

    We've been able to reproduce and pinpoint the problem.

    This is our suggestion to the portal developers:

    Using the HTMLB component we've come across a problem in combination with internet explorer memory management;

    more specifically the garbage collector of the Javascript engine.

    HTMLB extensively uses event handlers and 'anonymous nested functions'. Best explanation I found was here: http://jibbering.com/faq/faq_notes/closures.html#clMem and http://www.bazon.net/mishoo/articles.epl?art_id=824

    The result is that memory is not cleared until the browser is shut down.

    Simplest test to show this is reloading a large treeview page. Memory builds up; performance falls even after a small number of reloads and eventually script errors

    can occur because of threads accessing information that's still being reloaded. Although the behavior is most clear with the treeview object the same principle goes

    for other HTMLB controls.

    To verify the theory we've added some code that completely 'nullifies' all elements in the DOMtree and this indeed cleans up the memory

    and makes sure performance is constant. (We used getElementsByTagName("*") and iterated trough the elements setting them to null on window.onunload).

    This last approach is not feasible since iterating through the complete DOM tree is too time consuming.

    Manually cleaning up the objects HTMLB has created is not possible either because the names are dynamically generated.

    A suggestion for a solution to the problem would be that HTMLB generates code that cleans up the memory itself.

    One suggestion I read was creating an array in javascript that stores all tagnames that contain the eventhandlers.

    Iterating this array on unloading the window and setting these elements to 'null' would clean up the memory without costing much time.

    HTMLB could be made generate the necessary script to solve the memory and performance problem

    Right now we're using a workaround. The treeview is opened in a modal form and posts it's selection back to the main application page.

    After the modal form automatically closes the memory is freed.

    Hope this helps!

    Best regards,

    Jelle Bloemsma

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.