Taking this as an opportunity we want to announce the next dojo.beer() in Barcelona on June 17th.
You can get all info about the event on the DojoCampus event site.

The day after, we are speaking at the Mobile2.0 developer day and will give a detailed introduction in how to write mobile applications using the Dojo Toolkit and making sure they are running on different platforms such as PhoneGap and the W3C widgets being supported by Vodafone.

If you are in Barcelona that week, feel free to get in touch and if you have time to join for drinks during the dojo.beer or the mobile 2.0 conference let us know. Please sign up using the poll below.

Para los españoles :-)

Como Wolfram ha escrito en su último artículo de blog, nosotros estamos muy involucrados en el mundo de los móviles y estamos especialmente investigando como desarollar de la mejor manera para dispositivos móviles con Dojo.

Aprovechamos esta oportunidad para anunciar el próximo dojo.beer() en Barcelona el 17 de junio de 2009.
Puedes encontrar toda la información en inglés sobre el evento en la página de eventos de DojoCampus.

Al día siguiente vamos a dar una ponencia en el Mobile2.0 developer day y vamos a explicar como escribir aplicaciones moviles usando el Dojo Toolit y como asegurarse de que funcionan en múltiples plataformas como PhoneGap y como W3C Widget apoyado por Vodafone entre otros.

Si estás en Barcelona durante esa semana y te apetece contactar con nosotros no dudes en venir a tomar una copa al dojo.beer o a la conferencia mobile2.0. Por favor participa en el poll abajo si quieres ir.

For me as a front end engineer and JavaScript lover I always think twice before I set up a server system with a database and some Python or PHP code in between which then provides me with the data I need. This is painful, actually too much work for a lazy front-end dev like me, I would also have to do the permission handling and let alone the maintenance. Of course there are projects where it is not possible to store everything in the cloud, as what would be the solution I would favor over the before mentioned server infrastructure. (Let me just get this straight: by storing in the cloud I mean storing my data on mashable online services, which I can access via JavaScript, you will see in a second.)
Ideally JSONP is the solution of choice for getting the data, but sometimes there is not this choice and you have to look around for other ways.

Why JSONP?

The easiest and probably most relevant reason why to use JSONP (read here how it started), is that it is native JavaScript. There is no mapping from one format to another required, so you get natural performance. Second it is just a simple technique for cross-domain communication. And you don’t have to setup no complicated event handling for getting informed about when the data are loaded, it’s all handled.

Google spreadsheet

Let’s take this tiny spreadsheet, it contains the data I want to request, e.g. for showing on the uxebu.com website.

This spreadsheet is really easy to maintain, no geek knowledge is required for that, and this is the great thing about it. If that can serve as the data source for a web service or widget it just makes maintenance so much easier, and you can also tell your customer “just change the data as you like”. It’s not only, that changing is easy, also the permission handling is just a couple of clicks away. The data are hosted on one of the best working networks and you can be pretty sure that if you have no high-traffic site, that those data will just always be served at awesome speed. Enough reasons? I think so.

How to get the data

The google docs unfortunately show nothing really nice about JSONP. Yes you can make the ATOM feed of the spreadsheet be served as JSONP, but look at the data format (better don’t :-)), it really is not what you expect when working with JSON. The data are linear in there, so you have to apply the logic that actually the spreadsheet has in it again to reformat the data, and may be convert and take them apart again. Just believe me it’s not what one expects. If you like the pain, try it out.
And there is the CSV export of the data, that I always loved for it’s simplicity. Just add &output=csv to the URL and you get your spreadsheet as CSV. Very nice. Unfortunately trying to load those data using dojo.io.script.get of course fails:

CSV loading fails

JSONPed CSV

After trying a little bit and seeing the result that google spit out and fixing it again I had the solution (the spreadsheet below), pretty easy actually.

The CSV format is already comma separated, that is kind of half the way to JSON. At least the comma will make sure that we can distinguish the columns from one another. I ended up adding the callback name to the first cell on the left like this __callbackFunctionName__(' the opening parentheses and the apostrophe starts the function call that will be made inside the script tag you load it into. Now you can already guess that either every cell is surrounded by apostrophes, but that would just be too much hazzle and too error-prone, so I decided to just add a column before and one behind the data, when parsing the CSV those will just be dismissed, since they won’t contain a headline, therefore have no key to map the data to.
The last line is a little special, it contains the extra cell containing 0); which is closing the function, this is actually only there to create an extra column, where each line has just a space in it, so we get the comma at the end of every line. So that in the end our JSONPed CSV (the human-readable version here) looks just like this:

__cfn__(',name,url,status,irc, ',
',dojango,http://dojango.org,released,http://mibbit.com/chat/?server=irc.freenode.net&channel=%23dojango, ',
',dojodocs,http://dojodocs.uxebu.com,preview,, ',
',dools,http://code.google.com/p/dools,in progress,, ',
',xray,http://code.google.com/p/xray-project/,alpha,http://mibbit.com/chat/?server=irc.freenode.net&channel=%23xray, ',
',d.js,http://code.google.com/p/ddotjs/,unreleased,, ',0);


The client

Every line is now a parameter for our callback function. Simply use dojo’s dojo.io.script.get() hook onto the callback function and we got our spreadsheet data in any site within JavaScript. A little after-parsing and done.
The dojo source code may look like this:

dojo.require("dojo.io.script");
 
dojo.addOnLoad(function(){
    var url = "http://spreadsheets.google.com/pub?key=rmlQvp80ksEJg6r49fJhjuw&output=csv";
    dojo.io.script.get({url:url});
    dojo.connect("__cfn__", function(){
        var args = dojo._toArray(arguments),
            colNames = args[0].split(",").slice(1, -1),
            data = [];
        for (var i=1, l=args.length-1, d; i<l; i++){
            // Convert the data using the colNames to an object.
            // (Might be an esoteric step, but correct this way.)
            d = {};
            dojo.forEach(args[i].split(",").slice(1, -1), function(item, index){
                // Do some CSV conversion.
                item = item.replace(/\"\"/g, '"');
                if (item.charAt(0)=='"' && item.charAt(item.length-1)=='"'){
                    item = item.substr(1, item.length-2);
                }
                d[colNames[index]] = item;
            });
            data.push(d);
        }
        dojo.query(".theProjects")[0].innerHTML = dojo.toJson(data, true);
    });
});

You can download and try out a test page here.

Of course, there are a couple of drawbacks.

1. You have to make the spreadsheet adhere to a certain style, the first column, the last column, etc. and one error in there may break it entirely. So there is not much fault tolerance. Additionally you are not supposed to use new lines in the content of the spreadsheet!
2. The callback name is fix, though if you are using this sheet in one app this should be ok.

But see the advantages, you get permission handling for editors for free, you can let your customer edit the data without your involvement and so on. As always, when the use case requires this solution you can pull it out of your sleeve.
Oh, the source code above is also still not handling the escaped commas I guess, so there are still places where this can be improved.

Further thinking

Another way I though about was simply only surrounding the CSV by /* and */ which would relieve us from any JavaScript parsing error, since everything is a comment. But my quick test using innerHTML didn’t work. And innerHTML is not that relieable anyway so it might be better I didn’t waste more time on it. May be loading this into CSS tag enables us reading the data back … I don’t know, those are just random thoughts.
Another thought Nikolai had was “A spreadsheet-based CMS”. Of course, why not. You can basically store any kind of data in the spreadsheet, even HTML if you really would want to.

This can spin of more discussions and interesting ideas, let’s see what the future will bring.
The web is becoming more fun every day!

Well, call me pedantic for even discussing this and seeing this as relevant. But everybody knows that adhering coding styles make programming in a team way more pleasant and it is just way more efficient to just code and not to style! Which includes not having to think about how to style the code, though I realize that a lot of programmers have a problem adapting to coding styles.
We at uxebu basically defined that we are applying the coding guide lines of the project that we possibly contribute stuff back to. This means our JavaScript code applies the dojo coding style guide and our python stuff (we use internally) applies the django coding style guide.

But let’s look at the for-loop now.

The default

The most common usage of a for loop is the following.

1
2
3
4

for (var i=0; i<nodes.length; i++){
    var node = nodes[i];
    // whatever
}

Nothing spectacular here. But let’s take it apart a bit. There are two things that are commonly known that can be optimized.

1. The comparison “i<nodes.length” in line 1 evaluates the length of nodes on every iteration, if the nodes array is not modified while looping over it or the change to it is not relevant, this can be optimized.
2. Also the declaration of the variable “node” in line 2 is done multiple times, so this is just a small unnecessary thing to do.

So let’s optimize the things we just found out.

Version 2

1
2
3
4
5
6

var node;
var len=nodes.length;
for (var i=0; i<len; i++){
    node = nodes[i];
    // whatever
}

Another step on our way was to optimize the variable declarations and reducing their count from three down to one. In some code you can then see the following.

Version 3

1
2
3
4
5

var node, i=0, len=nodes.length;
for (; i<len; i++){
    node = nodes[i];
    // whatever
}

Actually we have already skipped a tiny step in between, very often you can see multiple var-statements as opposed to the already “squeezed” one-liner in line 1 above. The way of writing it as seen here, is reasonable if there are a couple other variables to be declared, you just need one var-statement. This will basically reduce the code size, if your minifier doesn’t already do that for you. As stated here it seems to be specified to be irrelevant to performance. So event the argument under 2. against the first version (see above) is not very strong.
Just a small side-note: the one line var-statement evaluates in declaration order, so something like this will work!

var arr = [1,2,3], len = arr.length, x = len-1;

The “len” and also “x” variables contain the proper content as you are expecting. The comma-separated var-statement evaluates the assignment expression by expression and steps on to the next assignment. Therefore “len” and “x” will have the proper values 3 and 2.
But let’s go back to our for-loop.

Version 4

If the var-statement is outside the for-loop and especially if other variables (outside of the scope of the for-loop) are declared there the source code get’s blury and harder to read. For example:

var someVar = whatever, anotherVar = [1,4,5], node, i=0, len=nodes.length;

The first two variable declarations (someVar and anotherVar) have nothing to do with the for-loop context, but the others do, so this blurs the source code and is prone to errors. Also if you separate this source code onto multiple lines like so:

var someVar = whatever, anotherVar = [1,4,5],
    node, i=0, len=nodes.length;

it is still a possible point of failure. I for example, forgot the comma on line 1 which made this source code

var someVar = whatever, anotherVar = [1,4,5]
    node, i=0, len=nodes.length;

still work. But and this is a big but, the code get’s a different meaning now! First, line 1 will work, since the semicolon at the end of the line is not mandatory. And second (if not declared inside this scope before) the variables on line 2 are now defined in global scope. And that can really cause a hard to find bug!
Another good reason for not doing this, is that extending the code may lead to developers adding code in between the var-declaration and the for-loop, for whatever reason. Then the variable declarations for the for-loop “drift away” and loose their context even a bit more. And the source code becomes harder to understand.

So we rather put all the variable declarations into the for-loop’s var-statement. Like so:

1
2
3
4
5

var someVar = whatever, anotherVar = [1,4,5]; // This is outside the for-loop and also looks like it.
for (var i=0, len=nodes.length, node; i<len; i++){
    node = nodes[i];
    // whatever
}

Now we have a pretty compact and well context-focused syntax for declaring variables needed within a for-loop. This code is nicely readable and has no impact on performance, even if in most cases good and maintainable code is worth more than the fastest code, but that’s a use case based decision! We are taking this as a standard for uxebu code.

What do you think? Let us know if you see potential for optimization.

Fast forwarding … what came out of it is the API docs viewer which, we here at uxebu, built over the christmas holidays. It is completely client-based, for creating the documentation and retreiving all the information, no server-side code is needed anymore, it’s all done in dojo.

If you want to see a detailed introductional video, sit back, relax and enjoy the following screencast:

Inline doc styles

There are a couple of JavaScript inline documentation tools and styles out there, but no real standard has evolved yet. Maybe because of JavaScript’s dynamic nature it’s hard to fix it to just one style. Though this just makes the task more interesting, actually.

Let’s take a step back and take a look at just three of the various different inline doc styles.

The jQuery way, pretty much textual.

// Execute a callback for every element in the matched set.
// (You can seed the arguments with an array of args, but this is
// only used internally.)
each: function( callback, args ) {

The YUI way, as you will see it’s very JavaDoc like, the method is documented above the actual definition and uses the @ sign for identifiers.

/**
 * Returns a string without any leading or trailing whitespace.  If 
 * the input is not a string, the input will be returned untouched.
 * @method trim
 * @since 2.3.0
 * @param s {string} the string to trim
 * @return {string} the trimmed string
 */
trim: function(s){

The dojo way, with proprietary identifiers, inside the function code!

dojo.trim = function(str){
	//	summary:
	//		Trims whitespace from both sides of the string
	//	str: String
	//		String to be trimmed
	//	returns: String
	//		Returns the trimmed string
	//	description:
	//		This version of trim() was selected for inclusion into the base due ...

We see that there are different levels of depth and explicitness in the inline comments. But they all have in common, that important and interesting information are contained inside the source code, that should be exposed to the users of those APIs.

The __doc__ approach

In python, a certain type of comments is available as the docstring property __doc__ of the function it is in. This was actually the initial idea, to provide the docs in this kind of way:

dojo.trim = function(str){}
dojo.trim.__doc__ = {
    summary:"Trims whitespace from both sides of the string",
    returns:{type:"String", summary:"Returns the trimmed string"}
}

It’s is pretty obvious, that this is is pretty ugly source code in the first place and secondly a comment is not a comment anymore but becomes source code. Prone to errors, and not really leading to higher productivity, we realized that this approach was actually just a learning stage.
Still it is pretty handy to use the command line in FireBug and have the docs at hand via autocompletion e.g. just typing dojo.trim.__doc__ and the docs are there (this feature is currently also implemented, but the __doc__ property must be generated by a function call afterwards and it is not in the main focus for the current state of the project).

The less disruptive approach

Since the __doc__ approach has the ugly side effect that library authors would have to change all their source code it was dismissed pretty quickly. New ways had to be explored. Driven by the flexibility of JavaScript and it’s dynamic nature we found a nice mix of reflection and minimal file parsing that allows us to extract the information from the existing raw (unpacked and not minified!) source code, without the need to modify it upfront.

First comes the reflection. Using the simple for-in loop over the prototype and the object itself allows us to extract all the methods and properties. Applying a little bit of logic using toString() and alikes and we know if the implementation of this object overrides, inherites or creates this method, we find out the default value of properties and a lot more. In the special case of dojo we can also easily find out the parent class(es). The reflection is actually worth a separate article, since it is quite powerful and allows deep insights into a class’s inner values.

Second step is simple file parsing. Since we know that object “foo” has the method “bar”, we know that in the source code we can find the definition by looking for the following patterns:

foo.bar = function(){}
// OR
foo = {
    bar: function(){}
}
// OR
foo = new function(){
    this.bar =  function(){}
}

There are a couple of special but rare other cases, but the patterns are very simple to detect as you can see. So our FileParser doesn’t really need to understand the JavaScript syntax, it is just looking for exact patterns and is therefore quite fast (we can surely still improve on the performance!).
Using regular expressions we also find out the parameters and the actual docstring itself, which then is parsed by the DocStringParser.

Let’s summarize. We have an object’s/class’s (if you want to call it a class) methods, properties, their according docstring and the docstrings of the class itself. We know the inheritance structure, can determine the type (public, private, etc.) from the name (for now we assume it is private when it starts with an “_”) or soon we will use the docstring identifier “tags” (which was just shortly introduced into dojo as you can see it used here). And we have example code, which is contained in a lot of docstrings. So this is already quite an amount of useful data. Let’s make them useable.

Plugging it all together

The pieces are there, they just need to be plugged together and hopefully a useful API docs viewer will arise. For this special dojo use case, we also had to build a mapper which enables the mapping of a namespace to the correct file(s). E.g. dojo.query() is actually a function inside the dojo object, which would naturally mean it is inside dojo.js, but in this case this method is in a separate file query.js which is “the knowledge” of the mapper.

Building the namespace tree was another challenge, loading all the files in the browser and inspecting the entire namespace via JavaScript would just be an aweful waste of resources. So currently there is a small python script which generates the JSON files which contain the contents of the tree to the left. But the high flexibility of using dynamic extending of objects (like e.g. NodeList-fx does) mixins and other things make it hard to rely purely on the generated contents of the tree, so they are partly hand-crafted too.

The UI is purely dojo, showing off some of the neat features, like the slick ExpandoPane. In my eyes it looks very nice, with a lot of attention to the detail. The UI was actually the part that needed the least time to build, thanks to Nikolai’s deep knowledge it was a piece of cake. There are of course a couple of glitches like the wrapping of the tabs, but hopefully this is just another kick in the right direction to speed up those kind of fixes. Because what is there is already much more than just the base of a GUI toolkit with some widgets, it is a full-fledged-ready-to-go-batteries-included-kick-ass set of UI components. (Ok, enough wallowing, yes I am biased :-).) So look for yourself and let us know what you think.

The future

As you know it too, working on those kind of projects always spins off a lot of new ideas. So we want to share some with you and maybe even get some help on some of them. First: we will put the source code out on google code (or alike) and it will be open for contributions, of course. We just need to do some renaming to ensure future-proof enhancements won’t just clobber this thing and make it unmaintainable.

Another idea is to configure the API docs viewer for custom namespaces and as long as the inline comments are dojo style it should be just a snap of a finger to get your own project’s API docs out. Well, actually the snap of a finger is the creation of the above mentioned JSON file, which contains the tree structure. But one day we will also have an auto-detector which builds the tree initially out of traversing through a given existing namespace (given that it is entirely loaded).

Idea No. 734 :-) was to provide the API viewer for other libraries too. The architecture is made this way, that the reflection and file parsing are separated and could be extended to work with another inline doc style syntax (we made first experiments with it). In order to do this right we think about having a common interface where to put and get the apidoc data from. A json-schema for API doc data is required. I have started on one, but this task really is huge when done right.

Of course the __doc__ property will be provided. Currently when working with libraries or function that I don’t know I mostly use toString() on it and learn from the source code. I could also very well imagine myself using __doc__ if it was there. So keep looking for that, I think it can change the way one uses the FireBug console and learns about libraries.

Since we know all the objects, methods on the one hand and the according docs on the other hand we can tell how good the doc coverage is. This heads into the direction of continuous integration and imho that is really where JavaScript still has a long way to go.

And there are a couple more ideas, like running the inline doctests in the UI, integrating the API viewer with Bespin and allowing to throw the api viewer onto any page using a bookmarklet, which would nicely let you browse the JavaScript API of any site, no matter if you want to learn, fix something or whatever. To mention just some of the ideas …

Now if you want to get your hands dirty and play with the code, see how it can integrate with your own code or just have offline dojo api documentation, drop us an email ( labs (a t) uxebu.com ) and we will make sure a copy of the code lands in your mailbox. Also, if you find bugs, have ideas, want to contribute, contact us and we will exchange ideas to make this tool the best available javascript api viewer out there.

Dtrace is a very powerful tool to take a deep and exact look into your systems internals. For us webdevelopers it is a great tool if want to investigate performance issues or bottlenecks within the browser.

A few dtrace details

Dtrace works by using probes provided by so called “providers” which are scattered throughout your system and also in important places in firefox. When starting a dtrace session those probes get activated and you can handle the information given by the probes.

Besides that, dtrace’s internal language D gives you many options of handling the data, making aggregations, predicative constructs and other features to give you a good view of what is happening.

Probe activation

To activate a dtrace probe first of all you need to know what probes are available on your system, in our case which probes are available through firefox. A simple

$ dtrace -l | grep -i "javascript"

should return a list of available probes looking like this:

24728 javascript13762    libmozjs.dylib                        js_Execute execute-done
24729 javascript13762    libmozjs.dylib             jsdtrace_execute_done execute-done
24730 javascript13762    libmozjs.dylib                        js_Execute execute-start
24731 javascript13762    libmozjs.dylib            jsdtrace_execute_start execute-start
24732 javascript13762    libmozjs.dylib                      js_Interpret function-args
24733 javascript13762    libmozjs.dylib            jsdtrace_function_args function-args
24734 javascript13762    libmozjs.dylib                      js_Interpret function-entry
24735 javascript13762    libmozjs.dylib           jsdtrace_function_entry function-entry
...

The first column is the probe ID, the second the name of the probe provider, the third the location of the probe, the fourth the name of the program function the probe is located at, and the last is the probe name.
Now when you want to activate a probe you use following schema:

provider:module:function:name

So to activate the “function-entry” probe we can write

javascript13762:libmozjs.dylib:jsdtrace_function_entry:function-entry

This is long to write, especially in our case since we would want to activate all function-entry probes. Se we can shorten this to

javascript*:::function-entry

A simple dtrace script

Now that we know how to activate a probe lets take a look at the dtrace script I was showing in the last blogpost:

sudo dtrace -n javascript*:::function-entry'{ @[copyinstr(arg1), copyinstr(arg2)] = count(); }' 
    -n END'{ printa("\n%-6s %-35s  %5@u", @); }'

lets split the dtrace call up in its most important parts:

sudo dtrace

here we execute dtrace with root privileges

-n javascript*:::function-entry'{ @[copyinstr(arg1), copyinstr(arg2)] = count(); }'

The parameter “-n” tells dtrace that we are about to enable a probe matching the name following the parameter. This is “javascript*:::function-entry”.

Now after enabling the probe, we are telling dtrace what to do with the information we get everytime that probe gets fired. In this case we do an aggregation on the times a function gets called. Similar to an associative array we store a “key” and call the dtrace internal function count() to increment the counter for every specific function call.

When activating a probe and that probe gets called you have access to several probe specific arguments which you refer to using arg0, arg1, arg2, argX. The function-entry arguments are:

arg0: filename
arg1: classname
arg2: funcname

Essentially in the above example, we are storing the class name and function name as the key for the aggregation.

The last unclear bit is the copyinstr call on both arg1 and arg2. copyinstr is used to copy the data from the user-space to the kernels address space. In short, copyinstr makes the information available to the dtrace script so we can output the info in a usable format.

The last part of the command actually is also activating a probe

-n END'{ printa("\n%-6s %-35s  %5@u", @); }'

Here we are activating the dtrace internal END probe

END

An exact same way of writing this would be:

dtrace:::END

which gets called at the very end of the dtrace execution. We use the dtrace function “printa” do return the data aggregation in a human readable format.
“printa” almost works the same as “printf”, most developers should know and basically takes a format string as the first argument and aggregation variable as the second string. In this example we use following format string:

"\n%-6s %-35s  %5@u"

Our aggregation variable has two touple identifiers, the classname and the function name. As a third available parameter we have the aggregation value itself (@[copyinstr(arg1), copyinstr(arg2)] = count();).

At first we make sure we print a “\n” for each new element in the aggregation, then left-align the first touple identifier (@[copyinstr(arg1), copyinstr(arg2)] = count();), fill up missing spaces up until 6 characters. The same we do with the second touple identifier (@[copyinstr(arg1), copyinstr(arg2)] = count();), though fill up more remaining space (up to 35 whitespaces) and at the end we display the actual aggregate information (@[copyinstr(arg1), copyinstr(arg2)] = count();). Note the “@” in “%5@u” which is used to access the aggregation information (count();).

To get a full overview of possibilities to format your aggregation using printa have a look at the dtrace documentation.

A step further

When debugging web-applications, we don’t want to type command line scripts every time but rather want to use a set of ready made scripts. Lets put the previous script into a file called “functioncall_count.d”:

javascript*:::function-entry
{ 
    @[copyinstr(arg1), copyinstr(arg2)] = count(); 
}
 
dtrace:::END
{ 
    printa("\n%-6s %-35s  %5@u", @); 
}

And execute the script using

$ sudo dtrace -s functioncall_count.d

When you load up a webpage, execute a few javascript function calls and then press CTRL+C you should get the same list of function calls as we did before.

Hands on optimisation

Now that we have a little bit of insight into how dtrace works lets look at a bottleneck occuring very often when building web applications: interaction with the DOM

A very often found bottleneck is the miss usage of appending DOM nodes into the DOM when being in an iteration.

Lets take a look at an example:

function buildMenu(){
    var cnt = 1000, node
        resultNode = document.getElementById("resultNodes");
    while (cnt>0){
        node = document.createElement("li");
        node.innerHTML = "Iteration "+cnt;
        resultNode.appendChild(node);
        cnt--;
    }
}

and compare the same with following code:

function buildMenu(){
    var cnt = 1000, node
        resultNode = document.getElementById("resultNodes"),
        frgm = document.createDocumentFragment();
    while (cnt>0){
        node = document.createElement("li");
        node.innerHTML = "Iteration "+cnt;
        frgm.appendChild(node);
        cnt--;
    }
    resultNode.appendChild(frgm);
}

Lets write a simple dtrace script which allows us to measure the execution time of such a iteration:

javascript*:::function-entry
/copyinstr(arg2) == $$1/
{
        self->ts = timestamp;
}
 
javascript*:::function-return
/copyinstr(arg2) == $$1/
{
        @times["time: ", copyinstr(arg2)] = avg(timestamp-self->ts);
        @counts["counts: ", copyinstr(arg2)] = count();
        self->ts=0;
}

At first we see that our dtrace script activates two probes or the javascript* provider:

function-entry
function-return

javascript*:::function-entry
/copyinstr(arg2) == $$1/
{
        self->ts = timestamp;
}

We see two new things:

/copyinstr(arg2) == $$1/

and

self->ts = timestamp;

Dtrace doesn’t know control structuures such as if, else, if else but is using a predicative syntax.
Basically all we are saying here is: “If copyinstr(arg2) equals the passed first parameter from the shell, execute the probe.”. This allows us to only watch specific functions within application execution and can save us a lot of time, analyzing data returned from a profiling/debuggin session.

The second unknown construct is self->ts = timestamp.
“self” allows us to store data in thread local variables so we can be sure that there won’t be any race conditions in multi threaded applications. This is not really an issue in the JavaScript environment but nevertheless its good practice to work this way. “timestamp” gives us the current timestamp in nanoseconds, this is way more accurate than most of the todays browser profilers.

Now the code for our second probe looks like following:

javascript*:::function-return
/copyinstr(arg2) == $$1/
{
        @times["time: ", copyinstr(arg2)] = avg(timestamp-self->ts);
        @counts["counts: ", copyinstr(arg2)] = count();
        self->ts=0;
}

We are creating two aggregations on the function name. One to calculate the average time of execution for the function and one for the amount of times that function got called.

See it in action

Lets take a look at a video demonstration so you can see what difference each of the two approaches make in your application.

JavaScript profiling with dtrace from uxebu on Vimeo.

To watch the video with better quality visit the vimeo site.

Results

After profiling the two different approaches with dtrace we can clearly see that using DocumentFragment within an iteration is faster than appending the node to the DOM straight away.

Appending nodes using DocumentFragment: 252ms
Appending nodes to the DOM within the iteration: 260ms

In our example, the complexity within the loop was still very low. If you are dealing with more complex constructs the performance gain can be significant.

What’s next

Until now we have seen ways to compare different implementations of the same functionality – meaning that we already have to know about a bottleneck. In the next article I will explain how we can spot potential weak spots in your application code and show you how you can use dtrace to make sure that your code optimizations are as effective as they can be.

We at uxebu use these techniques, when we are investigating peformance bottle necks, to find the most efficient way to interact with the DOM.

Building Firefox

it is recommended to build Firefox from a release source and not from trunk since you really want to profile your app in an production environment. You can build Firefox from head though some of the plugins won’t work.

1. Building preconditions

To build firefox you need to make sure that a few modules are installed:

Xcode

If Xcode is not yet installed on your machine get a copy at http://developer.apple.com/technology/xcode.html.

Mac Ports

You need Mac Ports to make installation of the following modules much easier. Get the .dmg here http://www.macports.org/install.php

Packages for building Firefox

The remaining two packages you will need from the ports repository are “libidl” and “autoconf213″
After you have installed Mac ports open a terminal and run

$ sudo port sync
$ sudo port install libidl autoconf213

2. Download Firefox

For this blog article we will download the 3.0.6 release from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.0.6/source/ – if you want to profile other firefox releases visit ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ and go to the proper VERSION/source directory.

You can get more useful information on how to download the source from trunk (mercurial) at https://developer.mozilla.org/en/Build_Documentation#Get_the_source

Once you have the source, move it into your home directory, extract it and go into the created “mozilla” directory in a shell.

$ cd ~
$ tar xf firefox-3.0.6-source.tar.bz2 
$ cd mozilla

3. Creating a build config

Create a file in your home directory ($ cd ~) with following content and save it under .mozconfig

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff
ac_add_options --disable-libxul
ac_add_options --enable-debug --disable-optimize
ac_add_options --enable-shared --disable-static --enable-dtrace
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
mk_add_options MOZ_MAKE_FLAGS="-s -j4"
mk_add_options AUTOCONF=autoconf213

4. Build Firefox

Make sure you are in the directory of the downloaded firefox source – this should be the “mozilla” directory and run

$ cd mozilla
$ make -f client.mk build

5. Launch the newly build firefox

$ cd obj-ff/dist
$ open MinefieldDebug.app

Testing dtrace

Fortunately dtrace already is installed on OSX 10.5 (My machine is running on 10.5.6).
Open a new shell and open for instance google.com. After the page has loaded switch back to the shell and enter

sudo dtrace -n javascript*:::function-entry'{ @[copyinstr(arg1), copyinstr(arg2)] = count(); }' 
    -n END'{ printa("\n%-6s %-35s  %5@u", @); }'

(Note that you have to paste the code in one line!)

We are using the “function-entry” probe which will give us the possibility to inspect each function call within the javascript code. This example is fairly simple and is just showing us how many times a function got called.

Now on the Google page open the dropdown of the top menu and close it again.
Back in the shell, terminate dtrace by pressing “CTRL+C” and inspect the output.

It should look similar to this

CPU     ID                    FUNCTION:NAME
  1      2                             :END 
<null> abs                                      1
<null> autosave_disable_buttons                 1
<null> autosave_enable_buttons                  1
<null> autosave_parse_response                  1
<null> autosave_saved                           1
<null> autosave_update_preview_link             1
<null> autosave_update_slug                     1
<null> blur                                     1
<null> clearInterval                            1
<null> complete                                 1
<null> isNaN                                    1
<null> open                                     1
<null> send                                     1
<null> setInterval                              1
<null> success                                  1
<null> getResponseHeader                        2
<null> j                                        2
<null> join                                     2
<null> match                                    2
<null> parseInt                                 2
<null> removeChild                              2
<null> appendChild                              3
<null> goUpdateGlobalEditMenuItems              3
<null> goUpdatePlacesCommands                   3
<null> removeAttribute                          3
<null> setRequestHeader                         3
<null> createElement                            4
<null> toString                                 7
<null> valueOf                                  7
<null> substr                                  11
<null> isCommandEnabled                        12
<null> concat                                  13
<null> setTimeout                              15
<null> substring                               16
<null> goUpdateCommand                         24
<null> encodeURIComponent                      26
<null> getControllerForCommand                 27
<null> toLowerCase                             27
<null> getElementsByTagName                    31
<null> updatePlacesCommand                     36
<null> goSetCommandEnabled                     60
<null> setAttribute                            61
<null> split                                   64
<null> getElementById                          92
<null> apply                                  191
<null> replace                                223
<null> test                                   268
<null> exec                                   356
<null> getAttribute                           359
<null> toUpperCase                            376
<null> shift                                  482
<null> unshift                                546
<null> call                                   654
<null> indexOf                                835
<null> push                                  2329
<null> <null>                                6251

In the next blog post I will explain how we can write more complex dtrace scripts which give us deeper insight into profiling our applications performance. We merely have covered the tip of the dtrace iceberg so watch out for the next dtrace update.

Thanks Johannes for the great talk!