The “Break it Down” Blog

Ars has a piece up about the Tracemonkey JavaScript engine work that we will first see in Firefox 3.1 (currently in nightlies) but is the first part of major JavaScript work known as Tamarin that won’t be seen until Firefox 4.0.

Apparently the Mozilla JavaScript engine is getting worked over from the ground up with an optimization technique known as tracing. Tracing allows the execution path of code to be remembered between executions and saved, so any optimizations (e.g. loop-unrolling) that are performed during runtime in the VM, are written out, stored and re-used on the next launch. Benchmarks have shown that in some scenarios operations can be sped up 20-40x when this method is employed.

This particular approach has been discussed to death in the Java arena, mostly around 4 years ago when Java on the desktop was really crawling. A lot of the community members suggested that Sun modify the Java VM to do exactly this so on subsequent loads the fully optimized code would load instead of the Java VM optimizing the code on the fly every single time the app was started up.

With machines being faster now it isn’t such an issue, but it’s interesting seeing JavaScript going this route. Ars also makes the note that the tracing approach to optimization is popular with dynamic languages where runtime is the only time the app really takes it’s full form, I’m curious to see what this may do to the Ruby crowd and their VM work.

Update #1: Looks like the Mozilla group posted a screencast showing the difference in performance between the two engines when applying effects to an image in real time (like Brightness and Contrast). This more “real world” example looks to be about a 6x speed up, hardly the 20-40x “micro-testing” speedup reported, but hopefully this will improve with time as we work towards Firefox 4.

(Click to watch screencast)

Thanks Ars!