it would be better to show percent difference averaged across many inputs
Actual JavaScript Engine Performance
51–60 of 65 posts
Re: Actual JavaScript Engine Performance
#52Earlier 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 agree, your point is probably the most interesting thing and at the time of my comment IE10 beating Chrome seemed to be stealing the show. Hence my mention of the apples to oranges comparison.
Re: Actual JavaScript Engine Performance
#53V8/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 the engine implementation curve. Hopefully it will help push this optimization into the actual implementations.
Re: Actual JavaScript Engine Performance
#54If I was trying to think of something less representative of large well written javascript application I would have a hard time thinking of something better than JSLint. It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything
True. Let's be honest here. Most people are using jQuery to write new applications. Shouldn't we mostly be benchmarking jQuery and some common plugins? Maybe prototype as well. And benchmark the most common functions etc.
Chrome should just pre-compile jQuery using SSE and stuff, and provide a ABI/API.
Re: Actual JavaScript Engine Performance
#55I think even this test fails to capture true JS performance due to it's lack of DOM performance testing. This may not be terribly fair - is the performance of the DOM API still "Javascript"? - but then again, I'd prefer "useful" over "fair." Most of my JS tends to interact with the DOM in some manner, so it won't really matter if the pure JS stuff screams if the DOM is slow. Another question: Crockford claims that JS…
I study visualization websites frequently, and found Chrome much faster than other browsers (among all stable releases). Example page (not sure how well written): http://vis.stanford.edu/protovis/ex/force.html
Make sure you're using mozRequestAnimationFrame() and not setInterval(). This is by far the commonest reason for slow performance in Firefox 4.x. I looked through your source and found only setInterval(), so that may be the problem.
Re: Actual JavaScript Engine Performance
#56"So I have come up with a benchmark that should be more representative of large, well-written JavaScript applications. It is in fact a popular, large, well-written JavaScript application: JSLint." Translation From Crockford Speak to English: So I have come up with a benchmark that should be more representative of my code . It is in fact my code .
That's kind of mean.
Re: Actual JavaScript Engine Performance
#57You can debate the validity of Crockford's claims all you want, but I think you're missing the point.
This exercise just shows how silly benchmarking is, especially when all the contenders are "sufficiently good."
Re: Actual JavaScript Engine Performance
#58V8/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…
I don't see why it's an issue that Object.create is used, as long as attributes are assigned in a consistent order the optimization should still hold, since each assignment (or read) site would be monomorphic with respect to the current map (to use the Self terminology), even if the type isn't a useful indicator. (If I'm horribly off let me know, I'm using my knowledge of PyPy to try to make some guesses about how pr…
In V8 Object.create(arg) is implemented roughly as var o = {}; o.__proto__ = arg. The first statement sets the default hidden class for the newly created object. Since hidden classes in V8 capture the prototype structure as well, it has to change in the second statement. Now the problem is that unlike with normal properties no hidden class transition happens and we get a brand new hidden class each time.
Re: Actual JavaScript Engine Performance
#59If I was trying to think of something less representative of large well written javascript application I would have a hard time thinking of something better than JSLint. It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything
True. Let's be honest here. Most people are using jQuery to write new applications. Shouldn't we mostly be benchmarking jQuery and some common plugins? Maybe prototype as well. And benchmark the most common functions etc.
There's http://dromaeo.com/?jslib by John Resig. Chrome is pretty good at it.
Re: Actual JavaScript Engine Performance
#60Why is it centered around IE10? Seems biased. A researcher wouldn't do that.