Live data from Hacker News

Actual JavaScript Engine Performance

crockford.com

11–20 of 65 posts

Re: Actual JavaScript Engine Performance

#11
I 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 JSLint is more indicative of true JS performance, but doesn't really explain why. I think we're all predisposed to take him at his word, but I'd still like an explanation.

Re: Actual JavaScript Engine Performance

#12
post #10

Earlier quoted context omitted.

Could you provide links to recommended builds? If Crockford is reading maybe he can add them.

You can get installers for whatever the latest build is in each channel here: http://dev.chromium.org/getting-involved/dev-channel It's updated so frequently I'm not sure there's a better way to get a specific build.

For IE10 MS pushed out a CTP and said this is a good build to test with. Is there a build in the Chrome dev branches that are more vetted then others. I just wouldn't want someone wasting their time posting results and someone else saying, "Duh, it's obvious that Chrome 12.0.0.12.a had Javascript loop optimization turned off, didn't you read the commit logs? Those results are no good. You should go back to Chrome 12.0.0.5.c to get one that is usable for JS testing".

Re: Actual JavaScript Engine Performance

#13
post #10

Earlier quoted context omitted.

You can get installers for whatever the latest build is in each channel here: http://dev.chromium.org/getting-involved/dev-channel It's updated so frequently I'm not sure there's a better way to get a specific build.

For IE10 MS pushed out a CTP and said this is a good build to test with. Is there a build in the Chrome dev branches that are more vetted then others. I just wouldn't want someone wasting their time posting results and someone else saying, "Duh, it's obvious that Chrome 12.0.0.12.a had Javascript loop optimization turned off, didn't you read the commit logs? Those results are no good. You should go back to Chrome 12.…

Yeah, I certainly understand and appreciate the concern. I simply don't know if there's a set of specific builds for that purpose or I would have certainly included them.

Re: Actual JavaScript Engine Performance

#14
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.

Could you provide links to recommended builds? If Crockford is reading maybe he can add them.

The Chromium authors provide information on how to use newer builds here: http://www.chromium.org/getting-involved/dev-channel

There's also an AppleScript to download the latest 'stable' continuous build of Chromium (full disclosure: I wrote/modified parts of it) here: https://gist.github.com/370298

Re: Actual JavaScript Engine Performance

#15
post #10

Earlier quoted context omitted.

Could you provide links to recommended builds? If Crockford is reading maybe he can add them.

You can get installers for whatever the latest build is in each channel here: http://dev.chromium.org/getting-involved/dev-channel It's updated so frequently I'm not sure there's a better way to get a specific build.

You can get specific Chromium builds for most platforms here: http://build.chromium.org/f/chromium/snapshots/

Re: Actual JavaScript Engine Performance

#16
post #11

I 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…

Crockford claims that JSLint is more indicative of true JS performance, but doesn't really explain why. I think we're all predisposed to take him at his word, but I'd still like an explanation

"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"

Re: Actual JavaScript Engine Performance

#17
post #11

I 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

Re: Actual JavaScript Engine Performance

#18
post #11

I 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…

Crockford claims that JSLint is more indicative of true JS performance, but doesn't really explain why. I think we're all predisposed to take him at his word, but I'd still like an explanation "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"

[deleted]

Re: Actual JavaScript Engine Performance

#19
post #11

I 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…

Crockford claims that JSLint is more indicative of true JS performance, but doesn't really explain why. I think we're all predisposed to take him at his word, but I'd still like an explanation "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"

At the same time, "Programming Language Analysis Tool With Little To No Front-End or Real-Time Interaction" is not terribly representative of the average web application.

(what exactly is a "Javascript application" anyway? This seems like an attempt to pretend that JS is the only thing required to create a web application...)

Re: Actual JavaScript Engine Performance

#20
It is worth taking this with a liberal sprinkling of salt.

The first problem is that there is no documentation of method. It appears that the results were obtained by simply running JSLint on itself once. Without some indication of how the results are obtained and how stable they are it is essentially meaningless. Of course this is quite fixable but until it is fixed the data presented is basically worthless.

The second, and arguably larger, problem is that the page makes grandiose claims about the applicability of the benchmark that it doesn't even attempt to back up. In particular the claim that the performance on JSLint will be a better proxy for "other large, well-written JavaScript applications" than existing benchmarks. If we examine the Microsoft paper linked, it says:

"Specific common behaviors of real web sites that are underemphasized in the benchmarks include event-driven execution, instruction mix similarity, cold-code dominance, and the prevalence of short functions"

It is not demonstrated, nor is it obviously apparent, that JSLint will be any more typical in these respects than other benchmarks. I haven't examined the JSLint source code but I assume it isn't event-driven, deals mainly with string manipulation and makes many calls to the same few functions during parsing. If my guesses are correct it sounds like it will not, on its own, be a significantly better proxy for real-world performance than existing benchmarks. Of course it may be that it exercises a different subset of the ECMAScript engine than existing benchmarks; in this case a test like this would be a good addition to, rather than replacement for, an existing benchmark suite.

Post reply on HN