Wednesday, September 16th, 2009

Doloto, the JavaScript optimizer, released by Microsoft Research

Category: JavaScript, Microsoft, Performance

<>p>We posted on Doloto, the Microsoft Research project to help optimize JavaScript via code splitting. Ben Livshits and his team have now released the tool:

Doloto is an Ajax application optimization tool, especially useful for large and complex Web 2.0 applications that contain a lot of code, such as Bing Maps, Hotmail, etc. Doloto analyzes AJAX application workloads and automatically performs code splitting of existing large Web 2.0 applications. After being processed by Doloto, an application will initially transfer only the portion of code necessary for application initialization.

The rest of the application’s code is replaced by short stubs—their actual function code is transferred lazily in the background or, at the latest, on-demand on first execution. Since code download is interleaved with application execution, users can start interacting with the Web application much sooner, without waiting for the code that implements extra, unused features.

Doloto does very interesting work on your JavaScript. It rewrites the code and builds clusters:

and does function splitting and lazy loading:

What about the space savings? The team claims:

Doloto reduced the amount of initial downloaded JavaScript code by over 40%, or hundreds of kilobytes resulting in startup often faster by 30-40%, depending on network conditions.

Unsurprisingly, Steve Souders is a fan :)

Related Content:

Posted by Dion Almaer at 6:42 am
19 Comments

+++--
3 rating from 40 votes

19 Comments »

Comments feed TrackBack URI

I’m not all to happy with all the evals they include in the script.

Comment by V1 — September 16, 2009

Nice. Looks like it’s best used for features that don’t require immediate user interaction, else users will be waiting on network latency.

Comment by AaronHeckmann — September 16, 2009

Sounds very interesting, although is a Microsoft product :) I hope it will work fine. In fact beside the owner and the implementation, which I don’t think is bad, the idea of the product is really good. No one makes illusions about the large scale javascript applications and their role in the recent future.
I hope such products from other ‘companies’ will be fact soon! Thanks for the article.

Comment by stoimen — September 16, 2009

Can anyone comment on how they deal with the synchronous XHR problem this would seem to create? This line from the above sample:

var code = load(“f1″);

would seem to imply that the UI thread will have to block while fetching the code. I can’t see any way around this.

Comment by jgw — September 16, 2009

@jgw

I haven’t looked at Doloto’s procedure for loading code, but wouldn’t it be possible for the “load” function to simply load a tag in with an onload event to call the function you’re asking for? Then the UI thread would only be waiting for the DOM to complete the script insert and not have to wait on the network.

Comment by vvtim — September 16, 2009

If Microsoft would make all this effort to make their JavaScript engine as fast as Google Chrome’s, we wouldn’t need this.

Comment by randomrandom — September 16, 2009

@randomrandom
Excellent point. It does seem like Microsoft is putting a lot of effort into every technology except their web browser… Perhaps the Silverlight team should be assigned to implement HTML5 in IE9. :)

Comment by pianoroy — September 16, 2009

Can we just stop reporting on anything Microsoft does? All they ever do is re-invent the wheel and pretend they invented it or else make up new standards ignoring the existing ones (see point 1)

Comment by RoryH — September 16, 2009

The UI thread is blocked if you have a script tag in your HTML. Thus, if you download the JS via normal script tags, you will block for that entire period.

For example (and with easy math), let’s say that takes 10 seconds and five files (each taking 2 seconds). So the user must wait 10 seconds to interact. Now if first file lets the user start using the app after 2 seconds, but the user hits a function that is in the last JS file, they are stuck for 8 seconds — basically the same amount of time left blocking as the first option.

Of course, there are optimizations — like loading the JS files concurrently, and then using eval to make sure they execute in order where necessary. You might be able to avoid the eval too, if you first download the JS files so they are in the browser cache (XDR,IFRAME, IMG tags, css include, whatever), then use a script tag to load (from cache) and execute the file. I should test that… Anyway, the time may be far less than 10 seconds.

@vvtim: For a automated system, you can’t just make any arbitrary JS function calls into a callback. That would break the code that made the call.

I wish ExtJS had module background loading built in. Sadly, it is a little more oriented toward the intranet than the internet.

Comment by sroussey — September 16, 2009

All this Microsoft hate is disgusting, get a new line please.. they might not be quite on the ball with IE yet but they do a hell of a lot of amazing research that you’ll probably never even realize affects products/services you use.

Comment by meandmycode — September 16, 2009

@RoryH, you sound like a troll, but i’ll bite. Microsoft INVENTED Ajax with the XHR request object. Not Apple, sorry. Not Netscape, not Mozilla, not Google.. It was Microsoft. Microsoft was first to do a lot of things modern browsers are just starting to implement. In-browser 3D without a plug-in? Microsoft did it first with DirectAnimation/Direct3D. Custom fonts? Microsoft did it first. They don’t always wait around for standards to be built, and a lot of times that can back-fire for them, but don’t get all high and mighty saying that Microsoft is worthless. They do have their place in the world of the web, and a significant one at that.

Comment by leptons — September 16, 2009

@leptons: If they had actually invented stuff that wasn’t tied into Windows-only technologies (ActiveX, D3D, etc) people might think better of them… But of course this is rarely the case.

Comment by rasmusfl0e — September 16, 2009

> Microsoft INVENTED Ajax…

And how sorry they must be… They’ve mistakenly allowed the web to become the new OS. ;)

Comment by randomrandom — September 16, 2009

@meandmycode:

I don’t hate Microsoft. I was just stating a fact: They should make their #1 web-strategy priority to build a *great* browser that can compare with Google Chrome.

> they might not be quite on the ball with IE yet…

I like your optimism… If only MS hadn’t screwed with me so many times over the last 20 years…

OK, let’s hope Internet Explorer 9 will be as innovative as WebKit in supporting the new emerging W3C / WHATWG / Khronos web standards…

– Hey, I can dream! :)

We are on the same side people — we want standards-based web development. Let’s not forget that. Let’s keep our purpose in mind.

Comment by randomrandom — September 16, 2009

@v1: Usually, yea, it’s not a good idea to include a lot of evals. In this case, however, we’re using a slow eval to avoid a much slower network. That trade off ends up being worth it. Note that once we run eval and create the function object, we squirrel the function away so that we don’t run eval again.

@jgw: Doloto deals with the synchronous XHR problem by trying to avoid doing them. Primarily, Doloto adds background downloading of code to the program. If “f1″ has already been downloaded in the background, then the load() function won’t do a synchronous XHR. Doloto tries to make sure that the function has been downloaded by 1) prioritizing function download by time-of-first-use; and 2) downloading many functions together at the same time — e.g., if function f1 calls f2 calls f3, we’ll send all 3 of these functions to the client together. After all this work, there are some times when load() is called, the code hasn’t been downloaded in the background, and the program does have to do a synchronous XHR. In our experience this is relatively rare, but, when it does happen, it does cause the UI to hang. We’re looking at whether we can do a smarter analysis to always be sure to front-load the XHR at the very beginning of the event handler (where we think we could insert an async XHR without breaking program semantics), but that might not always be possible, and certainly is not in Doloto right now.

thanks,
Emre
emrek@microsoft.com (my email)
dolotofb@microsoft.com (doloto feedback)

Comment by emrek — September 16, 2009

@meandmycode – people we’re doing partial page loads before MS brought XHR to IE.

It is an interesting path of focus for MS given how IE desperately needs innovations to compete with Safari, Chrome and FF. At this day and age I’m not sure that a closed corporation can compete with products that benefit from open global developer communities.

This is all very interesting but complex web applications would probably be better served by using script caching via something like Gears. Only during the first load of a complex web app would such delays be of concern IMO.

Comment by mrfator — September 17, 2009

@mrfator – who was talking about XHR? wasn’t me.. you got your wires confused.

Comment by meandmycode — September 17, 2009

IE doesn’t need any of that innovation bollocks, it comes pre-installed on the worlds most popular OS

Comment by blueskiwi — September 22, 2009

Leave a comment

You must be logged in to post a comment.