Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Actual JavaScript Engine Performance

crockford.com

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Actual JavaScript Engine Performance

#61

Post by mdpm »

Tests are generally biased. Unless you're going to run each engine against a weighted distribution of operating systems (as relevant to your existing client base), on a weighted distribution of hardware architectures (ditto), using your application's library (weighted for real world use, like your clients do) - you're not going to see anything actually applicable. They're still going to be using the browser they use. The only applicable take away is 'module/class/function $x is performing badly in case $y on $environment/configuration $z and we should fix it'.

I'm assuming the use case of desktop, browser usage here, and not server usage. Regardless, there is no ultimate $engineA > $engineB that applies globally.

Re: Actual JavaScript Engine Performance

#62

Post by woodall »

azakai wrote: post #32
ktsmith wrote: post #6

Earlier quoted context omitted.

Comparing IE10 to Chrome 10 isn't exactly apples to apples. Chrome 11 or 12 should be compared to IE10 since those are the development versions.

> Comparing IE10 to Chrome 10 isn't exactly apples to apples. Chrome 11 or 12 should be compared to IE10 since those are the development versions. That is true - comparing an unreleased IE to a released Chrome isn't fair. However, the released Chrome was much slower than all other released browsers - Firefox, Safari, Opera, even IE9. Chrome usually does well on benchmarks, so it is interesting to see it doing so poor…

I wonder if this will/can effect node.js. Will they ditch V8 for the faster, free, javascript engine.

Re: Actual JavaScript Engine Performance

#64

Post by hokkos »

scott_s wrote: post #47
hokkos wrote: post #45

It is a Microsoft paper, a Microsoft test... be careful.

The paper ( http://research.microsoft.com/pubs/118663/paper_tr.pdf ) is an academic-style tech report by researchers, not ad-copy by people in HR.

We all know that academic parpers are biaised on who are funding it. There is event a paper on that.

Re: Actual JavaScript Engine Performance

#65

Post by mraleph »

allenwb wrote: post #53
ErikCorry wrote: post #40

V8/Chrome uses the constructor as a big part of the heuristic that determines the 'hidden class' of an object. The other part of the heuristic is the names and ordering of the properties on the object. Unfortunately, JSlint creates all its objects with Object.create and not with a constructor function. This causes objects with a similar structure to have a different 'hidden class'. This causes most of the optimizatio…

Interestingly, the 2nd argument to Object.create was specifically designed (by me) so that an object's "shape" could be statically determined. If the descriptor is all literals (they usually are) then each Object.create call site is essentially a construction site for a "class" of objects that share a common structure. As Erik says, this should be fixable. It sounds to me like Crock's coding style is just ahead of th…

Crockford's code style is very peculiar:

https://github.com/douglascrockford/JSLint/blob/master/jslin...

(I really hope that this is not coding-style-of-the-future)

As you can see single Object.create callsite becomes a construction site for objects that might _not_ share a common structure (they potentially have different prototypes).

Post reply on HN