3 ms·

V8: Chrome's JavaScript engine source code

48 points by mace 18y ago

cbetz 18y ago
There are now three engines vying for the title of the "fastest" JS engine: * Tracemonkey (Mozilla) * Squirrelfish (Apple/Webkit) * V8 (Google) I would love to see a benchmark comparison (Sunspider?) to see how V8 compares to Tracemonkey and Squirrelfish.
- johns 18y ago
  And let's hope this pushes MS into the race.
  - ashu 18y ago
    Or, completely out, perhaps? I mean, the race has been going on for a bit, now.
    - johns 18y ago
      IE isn't going away, so I think its in everyone's best interests that they are actively involved in the browser competition.
      - axod 18y ago
        Why so sure it's not going away?
        johns 18y ago
        Put yourself in their shoes and attempt to come up with one good reason why they wouldn't want to keep making a browser. They rarely get out of markets they're already in, and I don't think they're just going to forfeit a dominant market position just because the competition is better (see Windows).
        wheels 18y ago
        IE as an application is definitely here to stay, but I wouldn't consider it too off the wall for them to switch to one of the OSS HTML / JS engines. I don't expect it, but it wouldn't surprise me.
        axod 18y ago
        I didn't say they'd stop making a browser, I'd suggest people will just stop using it.
        stcredzero 18y ago
        If they do their classic strategy, it'll be "embrace and extend" with Javascript. The only problem is that their marketshare has eroded to the point where this might just cause their marketshare to erode even more.
- jmtulloss 18y ago
  Where does Tamarin land in this? They're working with Mozilla too, aren't they?
  - wmf 18y ago
    Tracemonkey adopted ideas and pieces of Tamarin.
- erik 18y ago
  I found a blog entry with some SunSpider runs: http://web-graphics.com/2008/09/02/scripting-engines-just-got-a-whole-lot-faster/ http://web-graphics.com/2008/09/02/scripting-engines-just-go... Unfortunately a TraceMonkey bug prevents direct comparisons.
  - ionfish 18y ago
    Brendan Eich posted some new numbers with a more recent TraceMonkey build. http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac...
- invisible 18y ago
  I'd bet V8 is a definite improvement over Tracemonkey. It really feels like V8 already improves the DOM manipulation/property getters/setters for DOM. Mozilla doesn't plan to do that until past 3.1! (Just find a site that has a lot of complex windows. Fastest link I could find: http://extjs.com/deploy/dev/examples/desktop/desktop.html http://extjs.com/deploy/dev/examples/desktop/desktop.html )
  - KirinDave 18y ago
    It probably feels faster because WebKit is really good about DOM manipulation. A lot of people don't seem to realize that the lion's share of time for a lot of JS stuff is in manipulating the DOM and re-rendering the page. Coupling an advanced javascript compiler/vm with a really quick rendering engine leaves you with what you feel there. Hard numbers, V8 is maybe 3x faster than WebKit nightlies on every benchmark suite I could find.
yan 18y ago
I have been grepping through the tree trying to find the implementation of the String class. A part of me thinks they just defined it in string.js and somehow made the rest of the code treat it as a cpp class.
- jlouis 18y ago
  it is not uncommon to patch primitives into your language by having special "__primitive" or something such annotations which can be added to call over a language barrier. In this case, you would annotate certain Javascript functions/classes so they refer to their C++ equivalent code. You gain the advantage that the difference between library code and primitive built-in things blur more so one function can be implemented as a javascript function (because the compiler already produces good code for that part), while another function (un-implementable in JS) is C++.
- shadytrees 18y ago
  I think (fuzzily), from what I can find, that string-stream.cc allocates a block of char's for a string. Once the string grows beyond the capacity, `char* HeapStringAllocator::grow(unsigned* bytes)` doubles the size of the allocated buffer. Kind of disappointing after half an hour of reading and C-s'ing in Emacs. `string.js` is used by `tools/js2c.py` to create a `string.h`, but otherwise I think many of the string functions are implemented in JavaScript and (I'm guessing) compiled later since `string.js` and other JavaScript files are referencing C macros.
stcredzero 18y ago
Now this runs a lot faster: http://www.abrahamjoffe.com.au/ben/canvascape/ http://www.abrahamjoffe.com.au/ben/canvascape/
jlouis 18y ago
It is obvious that the "older" JS-engines were not built for executing applications, but more for running small in-expensive things on homepages. As of the later years, JS has become pretty heavy and people use it a lot more. The genius here is to recognize that most of the cool work done to Smalltalk and Self applies equally well to Javascript. It feels like cheating, but the V8 team is actually just picking some low-hanging fruit done with research in the 90's. They push the envelope for what we can use JS for and that is a really good thing!

48 points by mace 18y ago

cbetz 18y ago

There are now three engines vying for the title of the "fastest" JS engine: * Tracemonkey (Mozilla) * Squirrelfish (Apple/Webkit) * V8 (Google) I would love to see a benchmark comparison (Sunspider?) to see how V8 compares to Tracemonkey and Squirrelfish.

johns 18y ago
And let's hope this pushes MS into the race.
- ashu 18y ago
  Or, completely out, perhaps? I mean, the race has been going on for a bit, now.
  - johns 18y ago
    IE isn't going away, so I think its in everyone's best interests that they are actively involved in the browser competition.
    - axod 18y ago
      Why so sure it's not going away?
      - johns 18y ago
        Put yourself in their shoes and attempt to come up with one good reason why they wouldn't want to keep making a browser. They rarely get out of markets they're already in, and I don't think they're just going to forfeit a dominant market position just because the competition is better (see Windows).
        wheels 18y ago
        IE as an application is definitely here to stay, but I wouldn't consider it too off the wall for them to switch to one of the OSS HTML / JS engines. I don't expect it, but it wouldn't surprise me.
        axod 18y ago
        I didn't say they'd stop making a browser, I'd suggest people will just stop using it.
        stcredzero 18y ago
        If they do their classic strategy, it'll be "embrace and extend" with Javascript. The only problem is that their marketshare has eroded to the point where this might just cause their marketshare to erode even more.
jmtulloss 18y ago
Where does Tamarin land in this? They're working with Mozilla too, aren't they?
- wmf 18y ago
  Tracemonkey adopted ideas and pieces of Tamarin.
erik 18y ago
I found a blog entry with some SunSpider runs: http://web-graphics.com/2008/09/02/scripting-engines-just-got-a-whole-lot-faster/ http://web-graphics.com/2008/09/02/scripting-engines-just-go... Unfortunately a TraceMonkey bug prevents direct comparisons.
- ionfish 18y ago
  Brendan Eich posted some new numbers with a more recent TraceMonkey build. http://weblogs.mozillazine.org/roadmap/archives/2008/09/tracemonkey_update.html http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac...
invisible 18y ago
I'd bet V8 is a definite improvement over Tracemonkey. It really feels like V8 already improves the DOM manipulation/property getters/setters for DOM. Mozilla doesn't plan to do that until past 3.1! (Just find a site that has a lot of complex windows. Fastest link I could find: http://extjs.com/deploy/dev/examples/desktop/desktop.html http://extjs.com/deploy/dev/examples/desktop/desktop.html )
- KirinDave 18y ago
  It probably feels faster because WebKit is really good about DOM manipulation. A lot of people don't seem to realize that the lion's share of time for a lot of JS stuff is in manipulating the DOM and re-rendering the page. Coupling an advanced javascript compiler/vm with a really quick rendering engine leaves you with what you feel there. Hard numbers, V8 is maybe 3x faster than WebKit nightlies on every benchmark suite I could find.

yan 18y ago

I have been grepping through the tree trying to find the implementation of the String class. A part of me thinks they just defined it in string.js and somehow made the rest of the code treat it as a cpp class.

jlouis 18y ago
it is not uncommon to patch primitives into your language by having special "__primitive" or something such annotations which can be added to call over a language barrier. In this case, you would annotate certain Javascript functions/classes so they refer to their C++ equivalent code. You gain the advantage that the difference between library code and primitive built-in things blur more so one function can be implemented as a javascript function (because the compiler already produces good code for that part), while another function (un-implementable in JS) is C++.
shadytrees 18y ago
I think (fuzzily), from what I can find, that string-stream.cc allocates a block of char's for a string. Once the string grows beyond the capacity, `char* HeapStringAllocator::grow(unsigned* bytes)` doubles the size of the allocated buffer. Kind of disappointing after half an hour of reading and C-s'ing in Emacs. `string.js` is used by `tools/js2c.py` to create a `string.h`, but otherwise I think many of the string functions are implemented in JavaScript and (I'm guessing) compiled later since `string.js` and other JavaScript files are referencing C macros.

stcredzero 18y ago

Now this runs a lot faster: http://www.abrahamjoffe.com.au/ben/canvascape/ http://www.abrahamjoffe.com.au/ben/canvascape/

jlouis 18y ago

It is obvious that the "older" JS-engines were not built for executing applications, but more for running small in-expensive things on homepages. As of the later years, JS has become pretty heavy and people use it a lot more. The genius here is to recognize that most of the cool work done to Smalltalk and Self applies equally well to Javascript. It feels like cheating, but the V8 team is actually just picking some low-hanging fruit done with research in the 90's. They push the envelope for what we can use JS for and that is a really good thing!