Re-engineering and re writing is always expensive in the later stage of aproject. So, knowing performance-and memory-related issues with old browsers upfront will save you lot of time and moneyInternet Explorer 6 has the worst performance when it comes to Java Script execution speed and memory leaks; Internet Explorer 7 is much better. Fire fox and Opera provide the best performance on a large amount of Java Script and have almost no memory leak. Un fortunately, IE 6 is still the most used browser in the world. So, the majority of your users will still be using IE 6, which makes it a challenge to deliver a rich user interface to the browser while maintaining speed and reliability. In next sections, we will look at some Java Script performance issues in IE 6 and some major memory leak problems and their solutions.
Reducing IE Symbolic Lookups
A primary source of IE Java Script performance issues is the constant symbolic lookup. Symbolic lookup occurs whenever the Java Script engine tries to pair a name or identifier in the script with an actual object, method call, or property running in the context of the engine. For example, document. write will result in symbolic lookup on document object for the write function. Symbolic lookups are expensive, especially on DOM elements, because IE has to do a lookup on the DOM element’s interface and find the function/property that you need. To improve Java Script performance in IE, the first step is to reduce the number of symbolic lookups and help IE limit lookups to as small scope as possible.
Evaluating local variables
A variable is accessed based on a scope chain that resolves bac kward from the most specific scope to the least specific. Some times these symbolic lookups can pass through multiple levels of scope and eventually wind up in generic queries to the IE DOM, which can be quite expensive. The worst-case scenario is that your variable doesn’t yet exist and every level of scope in the chain is investigated, only to find that an expando variable(a dynamically defined property attached to a DOM element) needs to be created.
Example shows a classic example of a local variable lookup that results in creating an expando on the window object. When you try to access some _ variable, IE needs to see whether it is defined in the test( ) function; if not, it checks the parent function, then its grandparent until it reaches the window object. It then finds that there’s no property named some_variable to window object. So, it creates an expando and assigns the value to it. Next time you try to access that variable, it moves up the same lookup chain, but this time it finds the variable on window object
Symbolic lookup on local variables
The solution to this is to use the var keyword to ensure the variable is created in the local scope only. Example shows how you can force a local variable and thus limit symbolic lookup efforts for IE.
Solution to local variable lookup
This optimization is not IE-specific—other browsers will benefit from optimized code as well if they can do shorter symbolic lookups.
Reducing symbolic lookup on DOM elements
All binding in Java Script is late binding, not early binding like in compiled languages such as C#. Moreover, because Java Script is interpreted and not compiled, the Java-Script engine has no idea what will be next in line to do any compiler optimization. This means that each time you access a property, variable, or method, a lookup is performed. Within the DOM, this could mean an extensive search of the element to find the same property over and over again, only to return to the Java Script engine un changed from the previous request.
In Example, the innerHTML property on a div is accessed several times. Each time, the Java Script engine does a symbolic lookup on the div. The first statement is a plain assignment. But the following statements actually require two lookups each: to get the existing value and to set the combined value.
Example of performance degradation from repeated DOM lookups
In Example , the solution is to build a combined string first and then assign the string to the innerHTML property in a single assignment. This will clear the previous content and set the new HTML.
Faster code by eliminating repeated lookups
Speeding symbolic lookup by caching DOM elements, properties, and functions
Because local variables lookups are the fastest, you can benefit from performance improvement by caching DOM element properties and function references in local variables to access them easily. Local variables maintain a direct reference to the original item (by reference) and do not create or duplicate any item.
In Example, document. body is looked up over and over, which createsrepeated lookups for the body property on the document object. Storing the document. body in a local variable can optimize this performance.
Slow code on repeated DOM lookup
In Example, we have eliminated repeated lookups on the document object, which is a big object. Caching the body object’s childNodes property in a local variable will further optimize the code.
Caching the DOM element reference will make the code faster
Repeated calls to functions result in slow performance
Example shows how we can optimize two functions by caching node. append Child and my_function.
Cache functions in local variables
You will benefit from caching DOM properties, as well as your own Java Script functions, especially the ones that are defined at global scope, which is the Java Script engine’s last step in the symbolic lookup to find them. Generally, you will have some utility functions defined at global scope and use those utility functions repeatedly in many places. Caching those heavily used utility functions in local variables will give you some performance boost.
Mitigating Internet Explorer Memory Leak
A circular reference results when a DOM object contains a reference to a Java Script object (such as an event handling function) and that Java Script object contains a reference back to that DOM object. The garbage collector, which is a memory manager, collects objects that are not referenced by anything and reclaims their memory. The Java Script gar bage collector under stands circular references and is not confused by them. Un fortunately, IE’s DOM is not managed by Java Script. It has its own memory manager that does not understand circular references. As a result, when a circular references occurs, the garbage collector cannot reclaim the memory because it does not know whether the Java Script object needs the DOM object. The memory that is not reclaimed is said to have leaked. Over time, this can result in memory starvation. The more IE runs and leaks memory, the slower it becomes. Lack of memory makes other programs page to disk and become slower also. The operating system has too much paging to do between RAM and the page file on disk, so the computer gets slower. You have to close the browser to free up the RAM that IE has allocated and to return to normal operational speed.
Avoid using event handlers as closures
Cyclic reference can happen if global variables holding references to DOM objects or event handlers are defined as closures. Closures are functions that refer to free variables in their lexical context. When closures reference DOM objects, there’s no way to know when that object will be needed, so the object is never freed.
In Example, a closure is formed in the event handler where it references two variables outside its local scope. For example, the closure_test execution function completes and the local variables (img and div) are ready to be released, but the event handler on img needs both img and div to be alive when it is fired. Therefore, the Java Script engine cannot release the reference to the DOM objects. So, there are active references on both an image and a DIV. The IE gar bage collector will not be able to reclaim these elements’ memories even if explicitly removed from the DOM element by calling remove Child. They will remain in the memory forever and never be released, and IE will leak memory.
Example of a closure leaking memory
The first step to avoid closure leaking is to use the this keyword to refer to the element that fires the event. Example shows improvement in one step.
Preventing the image from leaking
Now IE can release someImage but not someDiv as the closure still holds the reference to the DIV. There are two workarounds to this problem:
Leak-free event handling
Use out-of-scope functions
However, there’s an even safer and better approach to event handling—out-of-scope functions. This ensures the callback function will never be able to hold onto any reference to local variables within the main function.
Example shows that by declaring the event handler function out of the scope, there’s no way the function can hold onto any variable reference inside the closure_step3 function.
Using out-of-scope functions for event callback
A . NET developer might think that Example is how C# code is written for event handling. But closures are the norm for event handling in Java Script. Most popular frameworks, such as Prototype, Dojo, and jQuery, and utility libraries like Script. aculo. us, are full of closures. Closure gives Java Script developers a powerful syntax to reduce code size significantly, so they are familiar with using closure for many purposes including event handling.
The best way, however, is to use ASP. NET AJAX Framework’s $addHandler and $removeHandler functions to subscribe/unsubscribe to events on DOM elements because they provide cross-browser implementation to work safely with events:
Subscribes to a specific event multiple times; when the event is raised, it fires the event handlers one after another. You generally call it using an out-of-scope function and avoid the closure problem.
Removes a specific handler from an event but leaves other handlers intact.
Removes all event handlers from an element, marking it safe to be reclaimed by the garbage collector (see Example ).
Using $addHandler and $removeHandler
function closure_safer( )
var img = document. getElementById('someImage')
Using $addHandler and $removeHandler (continued)
It is a good practice to remove all event handlers when you are done with an element. This ensures IE can collect the item properly. One thing to note: you can use $removeHandler and $clearHandler only when you have used $addHandler on an element.
Example shows a new function—$clearEvents—that calls the ASP. NET AJAX Framework’s $clearHandlers function to clear any event attached by $addHandler and then sets the common event handler properties to null. This ensures that all event handlers are cleared.
Remove DOM elements
To reduce memory leaks, you will have to remove unused events from DOM elements. However, it’s always difficult to keep track of DOM elements and ensure they are released properly. So, one handy way to clean up DOM elements and make them ready for the garbage collector is to remove all event handlers during the window. on unload event. There are some common elements where events are generally attached, e. g. , DIV, input, select, and hyper links. So, if you call $clearEvents on all such nodes, you can get rid of the majority of event handlers and make them safe for removal (see Example).
Safe way to release DOM elements during window. onunload
The window. on unload event is fired right before browser is closed or the user navigates away to a different page. During this time, cleaning up a majority of the event handlers will ensure you have removed as much of the memory leak as possible. However, expandos attached to DOM elements need to be released. It is difficult to find these expandos because you have to run through each and every property of a DOM element and set it to null.
Browsers will get stuck for several seconds if you do this for all DIV tags or all hyperlinks. There’s not much you can do about this, except hope most of the memory leak was resolved by removing the event handlers.
ASP.NET Related Interview Questions
|VB.NET Interview Questions||C#. NET Interview Questions|
|ASP.NET Interview Questions||ADO.Net Interview Questions|
|Windows Presentation Foundation(WPF) Interview Questions||Windows CE .NET Interview Questions|
|Dot Net Framework Interview Questions||Asp Dot Net Mvc 4 Interview Questions|
|Asp Dot Net Mvc Interview Questions|
Introducing Web Portals And Dropthings.com
Architecting The Web Portal And Widgets
Building The Web Layer Using Asp.net Ajax
Building The Data And Business Layers Using .net 3.5
Building Client-side Widgets
Optimizing Asp.net Ajax
Creating Asynchronous, Transactional, Cache-friendly Web Services
Improving Server-side Performance And Scalability
Improving Client-side Performance
Solving Common Deployment, Hosting, And Production Challenges
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.