Webmasters Gallery

David Mandelin has announced“a visualization of TraceMonkey performance, with the goal of revealing what the JS VM is doing, and why it runs certain programs fast or slow, so we can figure out how to make the slow ones fast too.”

David starts off explaining what TraceMonkey is about, and pieces together the activities:

• When TM starts running a program, it always starts by interpreting the program, exactly as in the non-tracing JS engine.
• When execution reaches a point where TM might want to start a compiled trace, TM spends a bit of time monitoring the execution: checking to see if it already has a compiled region, counting the number of times passed, and deciding whether to start a trace. Monitoring is a kind of overhead: while monitoring, TM isn’t running the user’s program, but monitoring is a necessary cost of finding and optimizing traces.
• If TM does decide to create a new compiled trace, it runs in the interpreter while recording the trace, including operations and types of values. During this time, it is running user code a little slower than the basic interpreter.
• When the trace is finished, TM compiles the trace to native code. This is another form of overhead.
• As I mentioned above, as part of monitoring, TM checks to see if it already has a compiled native trace starting at the current point. If so, TM selects the right trace and prepares to run it, which I call executing the trace. This is a third form of overhead.
• Finally, TM can be running native code compiled previously. Compiled native traces run 2-20x faster than the interpreter, with a typical speedup factor of about 2.5.

With these new eyes, David walks through various benchmarks to see how they are effected. Now that it is easier to see what is going on, the team should be able to optimize even faster.