The document compares the performance of JavaScript engines in different browsers. It discusses the V8 engine in Google Chrome, SpiderMonkey in Firefox, Chakra in Internet Explorer 9, and Carakan in Opera 11. Benchmarks show that V8 consistently outperforms the other engines, with Chrome 16 being 2-5 times faster than Firefox, Internet Explorer, and Opera in the Kraken and V8 benchmarks. The document attributes V8's performance to optimizations like hidden classes, dynamic code generation, and its garbage collector.
2. Table of contents
1. Introduction
2. V8 engine – Google Chrome 16
3. SpiderMonkey - FireFox 9
4. Chakra – IE 9
5. Carakan – Opera 11
6. Case study – Chrome vs FireFox vs IE vs Opera
7. Bibliography
2
3. Introduction
■ The performance of javascript engine is an important feature of a
web browser when developing a client web application.
■ The user will obvious be more satisfied if some elements of the
application are working better. In that case he may use that
browser where the javascript engine is much faster
■ By far, v8 engine used by google is faster than other browsers like
FireFox, IE 9 or Opera. This will be shown is the last chapter at case
study
■ So, regarding these, we will talk about in this presentation about
the improvements of all these engines . Also the statistics at the end
of presentation will show the results of every engine
3
4. V8 Engine – Google Chrome 1
■ V8 is Google's open source JavaScript engine
■ V8 is written in C++ and is used in Google Chrome, the open
source browser from Google
■ V8 can run standalone, or can be embedded into any C++
application
■ V8 increases performance by compiling JavaScript to native
machine code before executing it, rather than to execute bytecode
or interpreting it. Further performance increases are acheived by
employing optimization techniques such as inline caching
■ With these features, JavaScript applications running within V8 are
said to have an effective speed comparable to a compiled binary
4
5. V8 Engine – Google Chrome 2
Improvements:
1. fast property access + hidden classes
function Point(x,y){
this.x = x;
this.y = y;
}
var p1 = new Point(1,2);
var p2 = new Point(2,3);
- most JavaScript engines would store p1 and p2 like they don’t
belong to the same class, but in v8 p1 and p2 shares the same
hidden class.
2. Dynamic machine code generation
- javascript source code is compiled into machine code when first
execution occurs.
5
6. V8 Engine – Google Chrome 3
Improvements:
3. Garbage collector
v8 engine:
- stops program execution when performing a garbage collection
cycle.
- processes only part of the object heap in most garbage collection
cycles. This minimizes the impact of stopping the application.
- always knows exactly where all objects and pointers are in
memory. This avoids falsely identifying objects as pointers which can
result in memory leaks.
http://code.google.com/apis/v8/design.html
http://en.wikipedia.org/wiki/Inline_caching
6
7. SpiderMonkey – FireFox 9 1
■ SpiderMonkey: 30% faster
■ SpiderMonkey integrates type inference with Jaegermonkey JIT
compiler to generate efficient code
■ SpiderMonkey is written in C++ and contains an interpreter,
several JIT compilers (TraceMonkey, JägerMonkey, and IonMonkey),
a decompiler, and a garbage collector.
7
8. SpiderMonkey – FireFox 9 2
TraceMonkey
- TraceMonkey is the first JIT compiler written for the JavaScript
language
- The compiler was first released as part of SpiderMonkey in Firefox
3.5, providing "performance improvements ranging between 20 and
40 times faster" than the baseline interpreter in Firefox 3
- Instead of compiling whole functions, TraceMonkey operates by
recording control flow and data types during interpreter execution.
This data then informs the construction of Trace Trees, highly
specialized paths of native code
8
9. SpiderMonkey – FireFox 9 3
JägerMonkey
- JägerMonkey, internally named MethodJIT, is a whole-method JIT
compiler designed to improve performance in cases where
TraceMonkey cannot generate stable native code.
- JägerMonkey operates very differently from other compilers in its
class: while typical compilers work by constructing and optimizing
a control flow graph representing the function, JägerMonkey
instead operates by iterating linearly forward through
SpiderMonkey bytecode, the internal function representation.
Although this prohibits optimizations that require instruction
reordering, JägerMonkey compilation has the advantage of being
extremely fast, which is useful for JavaScript since recompilation due
to changing variable types is frequent
9
10. SpiderMonkey – FireFox 9 4
JägerMonkey
Mozilla implemented a number of critical optimizations in
JägerMonkey, most importantly Polymorphic Inline Caches and
Type inference
http://en.wikipedia.org/wiki/Type_inference
IonMonkey
IonMonkey is a compiler in the traditional sense: it translates
SpiderMonkey bytecode into a control flow graph, using SSA for the
intermediate representation. This architecture enables well-known
optimizations from other programming languages to be used for
JavaScript, including type specialization, function inlining, linear-
scan register allocation, dead code elimination, and loop-invariant
code motion
10
11. Chakra – IE 9 1
■ Chakra is the new JScript engine developed by Microsoft for their
upcoming Internet Explorer 9 (IE9) web browser
■ A distinctive feature of the engine is that it compiles scripts on a
separate CPU core, parallel to the web browser
■ Chakra improves the performance of the browser and the web
pages render and respond much faster
11
12. Chakra – IE 9 2
■ Chakra, fundamentally changes the performance characteristics
of JavaScript inside Internet Explorer 9. Chakra includes a new
JavaScript compiler that compiles JavaScript source code into high-
quality native machine code, a new interpreter for executing script
on traditional web pages, and improvements to the JavaScript
runtime and libraries. You can read more details on Chakra
at TechNet.
12
13. Carakan – Opera 11 1
■ So how fast is Carakan? Using a regular cross-platform switch
dispatch mechanism (without any generated native code) Carakan
is currently about two and a half times faster at the SunSpider
benchmark than the ECMAScript engine in Presto 2.2 (Opera 10
Alpha). Since Opera is ported to many different hardware
architectures, this cross-platform improvement is on its own very
important
■ The native code generation in Carakan is not yet ready for full-
scale testing, but the few individual benchmark tests that it is
already compatible with runs between 5 and 50 times faster, so it is
looking promising so far
13
14. Carakan – Opera 11 2
Improvements:
1. Automatic object classification
- A major improvement over this engine is in the representation of
ECMAScript objects. Each object is assigned a class that collects
various information about the object, such as its prototype and
the order and names of some or all of its properties
- Class assignment is naturally very dynamic, since ECMAScript is a
very dynamic language, but it is organized such that objects with
the same prototype and the same set of properties are assigned
the same class
14
15. Carakan – Opera 11 3
Improvements:
1. Automatic object classification
- This representation allows compact storage of individual objects,
since most of the complicated structures representing the
object's properties are stored in the class, where they are shared
with all other objects with the same class. In real-world programs
with many objects of the same classes, this can save significant
amounts of memory.
- For two objects with the same class, if the lookup of a property
"X" on the first object gave the result Y, we know that the same
lookup on the second object will also give the result Y. We use
this to cache the result of individual property lookups in
ECMAScript programs, which greatly speeds up code that
contains many property reads or writes
15
16. Carakan – Opera 11 4
Improvements:
2. Native code generation
- Although engine's bytecode instruction set permits the
implementation of a significantly faster bytecode execution engine,
there is still significant overhead involved in executing simple
ECMAScript code, such as loops performing integer arithmetics, in a
bytecode interpreter.
- In addition to generating native code from regular ECMAScript
code, we also generate native code that performs the matching of
simple regular expressions. This improves performance a lot when
searching for matches of simple regular expressions in long strings.
For sufficiently long strings, this actually makes searching for a
substring using a regular expression faster than the same search
using String.prototype.indexOf. For shorter strings, the speed is limited
by the overhead of compiling the regular expression
16
17. Carakan – Opera 11 5
Improvements:
3. Register-based bytecode
- The last couple of generations of Opera's ECMAScript engine have
used a stack-based bytecode instruction set. This type of instruction
set is based around a stack of values, where most instructions "pop"
input operands from the value stack, process them, and "push" the
result back onto the value stack. Some instructions simply push
values onto the value stack, and others rearrange the values on the
stack. This gives compact bytecode programs and is easy to
generate bytecode for
17
18. Case study – Chrome vs FireFox vs IE vs Opera 1
Now we will se some performance statistics using v8 and kraken
benchmarks.
V8 benchmark:http://v8.googlecode.com/svn/data/benchmarks/v5/run
Score
2500
2000
1500
1000 2085
1354
500 959
629
0
IE 9 Opera 11.6 FireFox 9 Chrome 16
18
19. Case study – Chrome vs FireFox vs IE vs Opera 2
Now we will se some performance statistics using v8 and kraken
benchmarks.
V8 benchmark:http://v8.googlecode.com/svn/data/benchmarks/v5/run
Browser Speed
Google Chrome 16 2085 ms
Opera 11.6 959 ms
FireFox 9 1354 ms
IE 9 629 ms
The biggest score indicates the browser’s engine with the best
performance
19
20. Case study – Chrome vs FireFox vs IE vs Opera 3
Now we will se some performance statistics using v8 and kraken
benchmarks.
Kraken benchmark:http://krakenbenchmark.mozilla.org/
Time in milliseconds
60000
50000
40000
30000
55878
20000 42685
10000
13399 15315.4
0
Chrome 16 FireFox 9 Opera 11.6 IE 9
20
21. Case study – Chrome vs FireFox vs IE vs Opera 4
Now we will se some performance statistics using v8 and kraken
benchmarks.
Kraken benchmark:http://krakenbenchmark.mozilla.org/
Browser Speed
Google Chrome 16 13399.3ms +/- 1.8%
FireFox 9 15315.4ms +/- 0.6%
Opera 11.6 42685.0ms +/- 1.2%
IE 9 55878.0ms +/- 1.8%
Now time is being calculated in miliseconds and obvious the lowest is
the best engine
As we can see, Google’s v8 is the best engine by far, and the
statistics show this.
21
