This info is for v8-v5.
Almost all the time is spent in the function am3(), which is an integer arithmetic kernel that operates on arrays.
JM generates good code for am3().
Type specialization (Crankshaft/TI) is expected to give a big perf boost here.
See also bug 643565.
The benchmark builds a system of constraints and runs a solver. The constraints are represented by object-oriented data structures with several levels of wrapping. The bottom level is 'function OrderedCollection', which wraps a JS array.
Because of the many small functions that wrap each other in Java-esque style, this benchmark benefits strongly from fast method calls (o.f()) and/or inlining.
This benchmark also creates many objects and arrays, so allocation speed is also important. GC mark/sweep speed is not critical, but matters somewhat.
The benchmark does a lot of |array.length|, equality comparisons, and Array.push/pop, so making those faster would also help.
See also bug 643615
This is a mostly-mechanical Scheme->JS translation of two programs: earley, which does parsing, and boyer, which is a constraint solver. It has functions named 'sc_Pair' (like cons), 'sc_list', 'sc_append', and so on; the three just given are the ones that account for the most time.
Being based on Scheme, this program creates a lot of small objects, so fast object allocation and generational GC are very important. Inlined constructors would also help.
sc_list and sc_append use |arguments|, but only locally, so making this faster by not creating an arguments object would help. Same goes for call objects in closures.
The extensive use of closures also generate a lot of CALLNAME ops, so those need to be fast.
There is a lot of tail recursion, and also general tail calls.
See also bug 642001.
This is an object-oriented raytracer. It does a lot of arithmetic, for which JM generates good code. Type specialization would help a lot.
The main thing that needs to get faster here (other than type specialization) is object allocation, initialization, and GC.
See also bug 642002.
Description. Numerous kernels stuck together. A collection of regexp operations gathered from 50 popular websites, lightly modified, and run in succession.
Key features. Ninety-four different regexps are used in many calls to RegExp.exec() and String.replace(). The return values of these calls are never used.
Mozilla-specific things. We convert RegExp.exec() to RegExp.test() if the result isn't used, or is only tested for null (bug 581595). This speeds the test up by about 1.8x.
This is a simulation of an OS process scheduler.
The main things that need to be fast here are method calls, property lookups, and equality comparisons.
See also bug 643639.
This does a bunch of junk with splay trees.
It is mostly a GC benchmark, with fairly short-lived objects. It also needs fast allocation.
See also bug 643643.