V8bench Info

From MozillaWiki
Jump to: navigation, search

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.