Reply to: Trying out Chrome - how do they make it so fast?

[NickFitz]

For the love of God Nick, get a job!

This IE6 bug on the Private Messages page kept me busy for a while today

[d000hg]

For the love of God Nick, get a job!

[NickFitz]

That's very clever, but obviously relies on the programmer using Javascript's pesudo-class implementation (i.e. using a constructor function). If the programmer just uses new object() and adds properties to it willy nilly, then it can't possibly do the same as it has no way of knowing what the properties will be. May as well have classes; it's less confusing than messing about with prototypes.

No, that's just the way Google chose to present their example. Dynamic adding (and removal) of properties is the case that this technique is designed to address: given that the technique of using pseudo-constructors is just a special case of the general case of adding properties to instances of Object, they solved the problem for the general case, not the special case.

For example, the following code:

var foo = {};
foo.bar = 1;
foo.baz = 2;

var blob = {};
blob.bar = [];
blob.qaz = 'a';

var x = {};
x.bar = foo;

will result in the following activity within Chrome:

// assume hidden class A represents an object with nothing but default properties
foo becomes an instance of existing hidden class A;
foo has property "bar" added: it becomes an instance of new hidden class B, which descends from A;
foo has property "baz" added: it becomes an instance of new hidden class C, which descends from B;

blob becomes an instance of existing hidden class A;
blob has property "bar" added: it becomes an instance of existing hidden class B;
blob has property "qaz" added: it becomes an instance of new hidden class D, which descends from B;

x becomes an instance of existing hidden class A;
x has property "bar" added: it becomes an instance of existing hidden class B;

// so at this point:
//     foo is an instance of C
//     blob is an instance of D
//     x is an instance of B

delete blob.qaz;
// blob can now go back to being an instance of B

There's more to it than that, but that's the basic principle of creating hidden classes; with those classes backing the objects, such things as accessing blob.bar no longer involve accessing a dynamic property lookup (as in traditional implementations), as class B knows the specific offset of that property within the memory allocated to hold that object.

Although Google's examples use the "new" keyword and constructors, all that really does is the same kind of thing as the above, with the addition of setting the "prototype" property of the new object. According to Brendan Eich, this was only added to the language at the behest of Netscape's marketing people, who wanted it to look more like Java. At ClientOrg last year, we outlawed the use of "new" almost completely and didn't miss it.

I was more referring to the low level lack of type problems. For example, in C++, if you have a + b and the compiler knows a and b are ints, then it just inserts the code to add two ints In Javascript, it doesn't know what the types are, so you end up with this sort of thing:

typeA = GetType(a)
typeB = GetType(b)

if(typeA == int AND typeB==int)
{
   integerAdd (a,b)
}
else if (typeA == string AND typeB == string)
{
  stringAdd(a,b)
}
else if(typeA == string AND typeB == int)
{
  AddIntToString(a,b)
}
else ....

You get the idea. I've worked on a Javascript interpreter (one that produces a stack based bytecode and interprets it), and that's the sort of thing it has to do all the time and not suprisingly slows everything up (it also does the property name lookups by string compares!). Unfortunately I can't really justify rewriting it.

Anything involving mutiple if...elseif cases (or switch statements, which are the same thing) is crying out for lookup tables (or a more OO solution). I would have gone with something like (pseudocoded in JS, just for simplicity):

function concatenateStrings(first, second) {
    // allocate new buffer having length first.length + second.length
    // copy first into new buffer
    // copy second into new buffer at offset first.length
    // return new buffer as type string
}

function concatenateStringAndNumber(string, number) {
    return concatenateStrings(string, number.toString(10));
}

function addNumberAndString(number, string) {
    return addStringAndNumber(string, number);
}

function addNumberAndNumber(number1, number2) {
    // return the sum of the two numbers
}

addFunctions = {
    string: {
        string: concatenateStrings,
        number: concatenateStringAndNumber
    },
    number: {
        string: addNumberAndString,
        number: addNumberAndNumber
    }
};

function whatWeDoWhenAdding(value1, value2) {
    addFunctions[typeof value1][typeof value2](value1, value2);
}

Although most implementations use hashed dictionary lookups for properties, Google's hidden classes fix that.

I'm sure the new engines are very clever and can predict a lot to solve these problems, but it can't predict everything. But it could with the relatively simple addition of strong typing.

I tend to be pretty disciplined about passing and returning the correct types in my JS code, but enforcing strong typing would remove too much of the flexibility from the language, and that is one of its major strengths.

And Google obviously agree with me about JS not matching true native code because they're pushing ahead with their plans for sandbox'd downloaded native code.

Google's Native Client is an interesting project, but it isn't intended to supplant JavaScript. Not even Google expects people to start firing up gcc and compiling executables for the sake of sticking a drop-down menu on a web page.

[d000hg]

JS doesn't need to be as fast as C++... few apps are written in C++. If they can get it as fast as Java or Python that's good enough...

[VectraMan]

The language is dynamically typed, but that doesn't mean that the runtime has to lose performance by doing dynamic property lookup. V8 internally converts dynamic JS objects to hidden classes. For the vast majority of cases, the code runs with the same advantages as statically-compiled code.

That's very clever, but obviously relies on the programmer using Javascript's pesudo-class implementation (i.e. using a constructor function). If the programmer just uses new object() and adds properties to it willy nilly, then it can't possibly do the same as it has no way of knowing what the properties will be. May as well have classes; it's less confusing than messing about with prototypes.

I was more referring to the low level lack of type problems. For example, in C++, if you have a + b and the compiler knows a and b are ints, then it just inserts the code to add two ints In Javascript, it doesn't know what the types are, so you end up with this sort of thing:

typeA = GetType(a)
typeB = GetType(b)

if(typeA == int AND typeB==int)
{
   integerAdd (a,b)
}
else if (typeA == string AND typeB == string)
{
  stringAdd(a,b)
}
else if(typeA == string AND typeB == int)
{
  AddIntToString(a,b)
}
else ....

You get the idea. I've worked on a Javascript interpreter (one that produces a stack based bytecode and interprets it), and that's the sort of thing it has to do all the time and not suprisingly slows everything up (it also does the property name lookups by string compares!). Unfortunately I can't really justify rewriting it.

I'm sure the new engines are very clever and can predict a lot to solve these problems, but it can't predict everything. But it could with the relatively simple addition of strong typing.

And Google obviously agree with me about JS not matching true native code because they're pushing ahead with their plans for sandbox'd downloaded native code.

[NickFitz]

Chrome doesn't support NoScript plugin, so for that reason I'm out.

NoScript isn't a plugin, it's a Firefox extension, so it's hardly likely that a different bit of software will support it.

If you want NoScript for things like blocking JavaScript, blocking images from advertising sites, or disabling plugins like Flash, then you can do all that in Chrome's preferences with no extension needed: go to the "Under the Hood" tab and click "Content settings...". Note that you have the option, for each of the content types shown there, of either blacklisting all sites and then adding acceptable sites to a whitelist, or whitelisting all sites and blacklisting unacceptable sites.

[Shimano105]

Chrome doesn't support NoScript plugin, so for that reason I'm out.

[NickFitz]

Point of order: just because something converts to native code doesn't make it as fast as native code. It's quite easy to convert interpreted bytecode to native code: you just make the native code do the things the interpreter would do. Doesn't make it the same as native code from a language like C++.

That depends on how you generate the code. V8 isn't a simple bit of kit doing trivial conversion from bytecode to native code by some proces akin to stringing a bunch of macros together: it creates a highly-optimised internal representation of the code, using a variety of techniques.

Seems to me JavaScript has a fundamental problem: it's still dynamically typed. If they'd get organised and adopt something similar to the ActionScript 2 style class system (as was in the now defunct ECMAScript v4 spec IIRC), a) it would become a much more realistic language for the larger scale applications webists want us to write and win over the real programmers, and b) strong types would help enormously with optimisation and in many cases could rival C++ for performance.

The language is dynamically typed, but that doesn't mean that the runtime has to lose performance by doing dynamic property lookup. V8 internally converts dynamic JS objects to hidden classes. For the vast majority of cases, the code runs with the same advantages as statically-compiled code.

Many of the details are available at the V8 project site (and of course it's open source, so you can read the code to see exactly what's going on if you wish).

It's a shame with all this newfangled attention on JavaScript, nobody's bothered to improve the language.

I think ECMAScript 5 adds much that is of value (particularly strict mode), and ECMAScript Harmony will move things on even further.

Quite impressive IE9 animation demos on that link above. Is using the GPU unique to IE9, or are Firefox and Chrome et al going to catch up?

I believe FF3.7 is scheduled to have it, and doubtless everybody else will follow suit sooner rather than later

[d000hg]

Um, dynamic typing is a deliberate feature of the language. If they wanted it to be C they'd have used C. Higher level languages let you write code faster do do more complex stuff, the job is then to minimise the performance impact that results.

[VectraMan]

For JavaScript, Google created their own scripting engine called V8 which uses a load of clever techniques to optimise execution. It also compiles to native code, rather than an interpreted bytecode, so JS applications can run at pretty much the speed of native code. This has led to a speed war amongst the browser makers: Firefox's TraceMonkey beats V8 on some benchmarks, Safari's Squirrelfish Extreme (which also compiles to native code) claims a 36% improvement over V8, Opera's Carackan (native code compilation again) hasn't quite caught up with WebKit and Chrome yet (though they're working on it), and the IE Team claim that the latest preview of IE9 has overtaken Firefox.

Point of order: just because something converts to native code doesn't make it as fast as native code. It's quite easy to convert interpreted bytecode to native code: you just make the native code do the things the interpreter would do. Doesn't make it the same as native code from a language like C++.

Seems to me JavaScript has a fundamental problem: it's still dynamically typed. If they'd get organised and adopt something similar to the ActionScript 2 style class system (as was in the now defunct ECMAScript v4 spec IIRC), a) it would become a much more realistic language for the larger scale applications webists want us to write and win over the real programmers, and b) strong types would help enormously with optimisation and in many cases could rival C++ for performance.

It's a shame with all this newfangled attention on JavaScript, nobody's bothered to improve the language.

Quite impressive IE9 animation demos on that link above. Is using the GPU unique to IE9, or are Firefox and Chrome et al going to catch up?

[d000hg]

ChromeOS is just a Linux variant with hacks in to only run on SSDs and prevent you installing any local applications. As Linux it doesn't need much resources the way they will be configuring it... but it's the fact they want to force you to run apps through the browser, so they control all the data-flow, which is a little creepy

[xchaotic]

As always Nick, superb.

My impression is that Chrome is just that tick or two faster rendering. On slow machines this is even more apparent. (to me anyway).

I think that's the idea that Google is having with ChromeOS: make it fast enough so that Google Apps can be run on hardware that is very cheap so that they can dish out £50 netbooks to people and keep on collecting data / serving ads...

I also don't really agree agree on the slimmed functionality, I downloaded Chrome developer channel version with some cool extensions like Speed Tracer (so I could optimise CSS rendering speeds) and at least for me, Chrome is already providing more useful developer tools than other browsers (with the exception of Firebug perhaps) and it will only get better.

[lilelvis2000]

As always Nick, superb.

My impression is that Chrome is just that tick or two faster rendering. On slow machines this is even more apparent. (to me anyway).

[NickFitz]

There are two major things that make Chrome seem so fast: the rendering engine, and the JavaScript engine. The first is going to make an impression in general surfing, and the second when using web applications such as Google Maps or Google Docs.

For rendering, Chrome uses Apple's WebKit, which also powers Safari: Apple spun it off as an open source project, so there are other browsers using it too, such as the Nokia S60 browser. (In fact, WebKit was itself a fork of the open source KHTML project.) The WebKit Architect is Dave Hyatt, who used to be at Netscape and Mozilla - he implemented tabs in Firefox amongst other things. He has blogged a lot about the work that goes into improving rendering performance: here's a post from his old (and no longer styled) blog about improving CSS performance. When the project went open source, the WebKit team blog was set up, but sadly he doesn't write so much any more.

One important policy they have on WebKit is that nothing is allowed to have an adverse effect on performance: if a change, or a new feature, makes things run slower then it simply can't be committed. This helps to avoid the problem of performance gradually decreasing as new capabilities are added.

For JavaScript, Google created their own scripting engine called V8 which uses a load of clever techniques to optimise execution. It also compiles to native code, rather than an interpreted bytecode, so JS applications can run at pretty much the speed of native code. This has led to a speed war amongst the browser makers: Firefox's TraceMonkey beats V8 on some benchmarks, Safari's Squirrelfish Extreme (which also compiles to native code) claims a 36% improvement over V8, Opera's Carackan (native code compilation again) hasn't quite caught up with WebKit and Chrome yet (though they're working on it), and the IE Team claim that the latest preview of IE9 has overtaken Firefox.

So, to sum up: Chrome is so fast because a bunch of smart people at Apple and Google worked really hard to make it as fast as possible, this has got the smart people working on other browsers also working really hard to try and beat it, and IE9 will be a vast improvement on IE8

Oh, and don't forget Google's Chrome comic book, which explains a lot of the internals

[d000hg]

Hands up everyone who really uses all the features of a given browser. I know I don't.

Same here. I'm not criticising Chrome, only giving my opinion how they keep it small and fast. IE and FF have been around a long time and are pretty huge applications, Chrome is very new.

I think it's only fast if you're impressed by the application starting quickly. In use, the different browsers seem much the same to me.

Agreed. Rendering pages is rarely any kind of issue compared with downloading the content, the exception being JS-intensive pages but even IE8 is pretty fast compared to previous generations of browsers so I'd argue the only non-experimental pages that would cause a problem are just badly written.

More that IE8 is a POS.

IE8/FF3 are roughly comparable as far as startup time goes, so unless you're saying FF is also a POS, you're just spouting misinformation. Do you want to sound cool like the other kids?