JavaScript & Metaperformance

Douglas Crockford

Yahoo! Inc.

Scheme SelfJava

JavaScript

Early implementations were optimized to time-to-

market.Gradual speed reductions due to

15 years of patching.

JavaScript becomes a hugely popular language anyway.

Frenzied Competition

Everyone wants to have the fastest JavaScript engine.

Load and Go

• JavaScript programs are delivered to the execution site in source form.

• It is compiled and executed immediately.

• This was to facilitate embedding of JavaScript programs into HTML...

• Which is now considered a bad practice. Interference with minification, compression,

caching.

Promotion of XSS injection.

No time for Optimizing

• ECMAScript programs are expected to start execution instantly.

• ECMAScript does not specify an executable format or a virtual machine.

• There is a tradeoff between off-line optimization and portability.

• Portability is the web’s most valuable feature.

An Interlude.

Remember Java?

• Java specified a Virtual Machine and an executable format.

• Java applets were to rule the world in the late 20th Century.

• The biggest failure in the history of software development. Failed security model.

Lack of portability (write once, debug everywhere).

Awful UI toolkit.

Horrendous startup times (classloading).

• These things were not a big problem in servers.

End of Interlude.

There does not exist an executable format that is

Secure

Highly optimizable

Highly portable

Optimize as you go.

Self.

How fast are the new engines?

That is complicated.

Lies, Damn Lies, and Benchmarks

• Benchmark Bias Promote patterns that engine

implementers want to implement.

Promote patterns that resemble benchmarks.

• JSMeter [http://research.microsoft.com/en-us/projects/jsmeter/]

• The benchmarks are not representative of real programs.

The engine makers are tuning to the benchmarks, struggling to produce the

best numbers.

Performance without measurement is meaningless.

They don’t know what else to do.

Life on the Web

• Web developers have a difficult time with the browser.

• Desire to produce applications that are highly responsive.

• Browser platform contains some deep inefficiencies.

• Little visibility into the causes of performance degradation.

The DOM Bottleneck

• If the JS engine were infinitely fast, most web applications would run about the same speed.

• Browsers spend most of their time in layout, painting, marshalling, styling, IO, etc.

• The benefit of faster JS engines is the enabling of new kinds of applications.

Life on the Web

• Out of frustration, many developers are dedicated to optimizing their JavaScript code, even though it is not effective.

An Interlude

The Drunk and the Lamppost Story

End of Interlude.

Premature optimization is the root of all evil.

Donald E. Knuth

Life on the Web

• Web Developers believe that they must optimize prematurely because they will not be given a chance to do it later.

• To choose between two language features, put each in a loop and run 1000 times. Always use the winner.

• Even if The difference was not significant.

The race is likely to go the other way in future versions.

This results in code that is more difficult to read or maintain.

They are trying to do the right thing.

They think themselves responsible and heroic.

This behavior of developers interacts badly with performance

benchmarks.• Benchmarks

• Engine performance

• Programming style

This behavior of developers interacts badly with performance

benchmarks.• Benchmarks

• Engine performance

• Programming style

The benchmarks

are discouragin

g good programming practices.

An Interlude.

Who am I to say what are good coding practices?

• I discovered that JavaScript has good parts.

• I developed programming patterns that make use of the good parts while avoiding the bad parts.

• I developed a code quality tool, JSLint, to help developers use the good parts more effectively.

End of Interlude.

I am concerned that the benchmarks are having

the unintended consequence of worsening

the language and its usage.

The benchmarks do not reflect the characteristics

of good programs.

So…

I designed a new benchmark.

• The benchmark is JSLint, measuring how long it takes to analyze jslint.js.

• It demonstrates real application behaviors that are not exercised in the other benchmarks, especially prototypal and functional patterns.

• It is a test only of JavaScript performance. It does not measure any of the other aspects of browser performance.

Browser Seconds

Chrome 10 2.80

IE 9 1.15

Opera 11 1.10

Safari 5 0.98

Firefox 4 0.95

IE 10 preview 0.56

Chrome 13 canary 0.54

JavaScript Performance (smaller is better)

Thank you and good night.