PerformanceTuning
Version 16, changed by carlavmott 02/02/2007. Show version history
OBSOLETE this page has been moved to the Dojo Book
Dojo Specific Tuning
Dojo's performance tuning centers around four areas:
- download
- parsing
- instantiation
- deferred download
If you are a widget developer, you might also be interested in ProfilingJavascript.
Download
Web server settings
First of all, you should set your web server so that javascript files etc. have "Cache-content" set so the browser doesn't try to reload them every time.
You should also use web server compression (mod_deflate on apache).
IE repeated image download
If you find IE is repeatedly downloading the same image, read this article for advice. This also helps get rid of ugly image flickering in IE.
Builds
Question: How do I speedup download of a page?
Answer: by building a custom dojo.js file.
Details:
Under typical circumstances current versions of Dojo load any code not available in your dojo.js file using XmlHttpRequest, and does it synchronously to make sure the modules are there for you "right away". FireFox (at least pre-1.5) does not cache pages fetched through XMLHttpRequest.
Different "editions" or "profiles" of Dojo are available, and each has a different set of functionality built-in to its dojo.js file. Since dojo.js loads through the normal <script> tag mechanism, it does indeed get cached.
Thus, to speedup download you should build a custom "edition" of dojo.js containing the modules your app needs. You need Java, and look at the buildscripts directory of the source.
The other advantage of dojo.js is that the javascript is compressed, to download more quickly.
Open issue: many widgets reference a template HTML file, which is downloaded via XMLHTTP and thus isn't cached. No workaround for this yet. There's talk of doing "string interning", which basically means sticking those strings into dojo.js
Also see the Dojo Package System for more information.
How to do a custom build:
If you look in the buildscripts/profile you will see profiles for different builds. You can copy one of these and then edit it to include just the things that you want (and it will automatically pickup any of those things dependancies). Then there is an ant build process that will actually do the build. Something like this:
ant -Dprofile=foo clean release
Parsing
Page load time is proportional to the number of nodes on the page, because dojo searches all the nodes to see if they are widgets. You can avoid this in these ways:
Specifying which nodes to search for dojoType widget tags
Something like this in the <header>:
<script> djConfig = { parseWidgets: false, searchIds: [] }; </script>
And then in the <body>:
<div dojoType="Button" id="button1">...</div>
<script>djConfig.searchIds.push("button1");</script>
...
<div dojoType="Button" id="button2">...</div>
<script>djConfig.searchIds.push("button2");</script>
...
You can also make the parser not search underneath a given node by doing this
<div parseWidgets="false"> ... no widgets in here, don't waste your time looking! ... </div>
One little known feature about searchIds usage is that if you add at least one searchIds, then the "body" (and so the whole) of the document will not be parsed at all, even when the djConfig.parseWidget=true. (See hostenv_browser.js 's makeWidget() function) I think this is a buggy behaviour, and the whole document should still be parsed if djConfig.parseWidget=true. A use case when this is simply necessary: you have a section where you turn off the parsing using the new parseWidget="false" flag. But if you happen to have some widgets inside, those must be parsed using searchIds. But because you've added one such, the whole page will not be parsed, but those parts may contain other widgets!
Reduce number of tags on a page
It sounds obvious, but many web pages have a lot of unnecessary markup. For example, instead of
<table ...>
<tr>
<td>Hello World</td>
</tr>
</table>
just do
<div class="foo">Hello World</td>
Instantiation
Time is proportional to the number of widgets on the page. No advice here.
Deferred Download
Instead of downloading your whole page at once, defer portions until the user needs them. For example:
<div dojoType="Tooltip" href="tooltip.jsp"></div>
<div dojoType="TabContainer">
<a dojoType="LinkPane" href="tab1.jsp">Tab #1</a>
<a dojoType="LinkPane" href="tab2.jsp">Tab #2</a>
</div>
Javascript Performance Tuning
Premature optimisation
Make sure that you are not trying to prematurely optimise your pages. Read How to profile and optimize Ajax applications by Brad Neuberg - a brilliant article that has guidelines on how to ensure that your efforts are productive and not retarded.IE Optimisation tips
IE + JavaScript Performance Recommendations - Part 1
IE7 has dramatically improved performance - a good article that contains links to tests for areas where IE6 is slow.
Will JavaScript Closure Memory Leaks Ruin My App?
On Sunday 20 November 2005 7:32 am, Bob Ippolito wrote:>> On Nov 20, 2005, at 3:54 AM, Christian Boulanger wrote: > >>> > I am using dojo.io.bind and need a reference to the calling object >>> > in the handler code. Not being a javascript geek, I am still >>> > confused about the closures stuff and how much it impacts >>> > performance. Is the following way an ok way of doing things or is >>> > there a better way? Would it make sense to add a parameter to >>> > dojo.io.bind which transfers the callingObject to the handler >>> > without need to create the closure? > >> >> Closures are fine to use all over the place. The only time it can >> matter is the specific instances when they cause circular references >> to certain kinds of objects that don't fully participate in the >> interpreter's garbage collection scheme (most commonly DOM objects in >> IE). and if you use dojo.event.connect() to set up your event handlers, you don't have to worry about it even then. In short, go nuts with the closures, just don't manually set properties on DOM nodes that include functions or objects. Regards Alex RussellVisit this link for more information about closures and memory leaks in IE.
