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.
Actual JavaScript Engine Performance
11–20 of 65 posts
Re: Actual JavaScript Engine Performance
#12Earlier 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.
Re: Actual JavaScript Engine Performance
#13Earlier 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.…
Re: Actual JavaScript Engine Performance
#14Earlier 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.
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
#15Earlier 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.
Re: Actual JavaScript Engine Performance
#16I 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…
"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
#17I 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…
Re: Actual JavaScript Engine Performance
#18I 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
#19I 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"
(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
#20The 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.