41–50 of 65 posts
Now who is going to mix this with DOM manipulation, so we can actually see how the end-user is effected. If the JS engine is crazy fast and the DOM renderer blows, it won't make a bit of difference, unless it's purpose is as a server technology.
Earlier quoted context omitted.
There are many server-side applications that do exactly what you just described and JavaScript is starting to move into that space. So this is quite relevant and will become even more so over time.
The original post was comparing client-side browsers, not server-side javascript engines.
and that aside I dont think its anywhere near a good test for server side javascript either, server side js in particular its bottlenecks are mostly about shifting bits, pulling stuff down from the database or retrieving from the http socket, they usually do some string manipulation as well but its fairly minor compared to io
If 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
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.
If 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
It can be argued what constitutes JS engine, and what makes other parts of browser. I'd tend toward `pure JS' view of the JS engine; excluding DOM document and DOM events. [0]
Measuring speed of `naked, bare' JS engine makes some sense, even if not directly for web developers and web users. As some other posters pointed out, JS itself may be used for server-side scripting or general data processing, where access to DOM may be irrelevant. Just raw JS and some custom API for I/O.
However, I don't trust this method of benchmarking fully. There are optimization techniques that may skew results quite a bit. I guess dead code optimization could end up taking whole loops out of JSLint's code, if there are no side effects. That was implicated in discussions about some earlier benchmarks by other authors.
----
[0] Not sure if it makes a strong case, but here goes: when Apple forked Konqueror's KHTML into WebKit, they used own JS engine instead of KJS.
It is a Microsoft paper, a Microsoft test... be careful.
If 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
> It doesnt touch the dom, is not event driven, doesnt involve loading lots of files and does not render anything. It can be argued what constitutes JS engine, and what makes other parts of browser. I'd tend toward `pure JS' view of the JS engine; excluding DOM document and DOM events. [0] Measuring speed of `naked, bare' JS engine makes some sense, even if not directly for web developers and web users. As some other…
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…
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…
(If I'm horribly off let me know, I'm using my knowledge of PyPy to try to make some guesses about how precisely V8 applies these techniques).