4 ms·
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 t
by ender7 16y ago
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.
- kenjackson 16y agoCrockford 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 16y ago[deleted]
- ender7 16y agoAt 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...)
- dandelany 16y agoSure, but all "large, well-written JavaScript applications" are not created equal. This test in particular tests JSLint's performance at parsing its own JS source file. How many large Javascript applications spend most of their runtime parsing Javascript rather than traversing the DOM? I suspect not many.
- scott_s 16y agoThat doesn't fly. It's missing an explanation of the characteristics of JSLint, and how those characteristics are often shared with other large JavaScript applications. My own personal intuition is that JSLint is not representative of typical web applications, so I need convincing. To get an idea of where I come from regarding this, check out "The Landscape of Parallel Computing Research: A View from Berkeley": http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-18... They systematically classified several different kinds of computational patterns, and explained how those patterns appear in application areas. I don't expect a blog post to have that level of rigor, but I expect something at least in that form.
- pjscott 16y agoI would recommend that anybody interested in parallelism check out the article you linked to. It can be a tad verbose, but it's got a lot of really good insights.
- OOSeven 16y agoI 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 http://vis.stanford.edu/protovis/ex/force.html
- bad_user 16y agoChrome 10.0.648 certainly does better than Firefox 4.0.1, when running on Ubuntu, for the example you gave. This has also been my experience; I don't know what these benchmarks are doing, but Chrome is still the fastest in my perception. Also, the article doesn't mention OS used for the tests. It is certainly of importance since the performance on Firefox 4.0.1 certainly suffers on Linux and Win XP, versus Windows 7 -- which makes the comparison unfair, and a good benchmark would certainly mention results on multiple OSes.
- Lennie 16y agoIt shouldn't matter much. The test was just a javascript-engine test, this test does not do any rendering by itself.
- cemerick 16y agoI agree; throughout the development of Clojure Atlas (which uses Raphael and arborjs heavily), I've observed this rough ranking: Chrome > IE >= Safari > Firefox
- ootachi 16y agoMake 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.
- dfox 16y agoMore than that, from studying various VM techniques it seems to me, that most optimizations that make Javascript fast for computation actually harm performance of calling into foreign code (like DOM) even more so because in most browsers where is often quite significant interface mismatch between JS VM and DOM code (like plain JS objects lying on separately managed heap from DOM objects).