Hacker News new | past | comments | ask | show | jobs | submit login

A couple odd things about this benchmark: IE9 runs different tests than the rest of the browsers. I'm not sure why, and there's no mention of this anywhere in the documentation. You can confirm this by running the benchmark - IE9 completes it much quicker than the other browsers, and if you click to see the results, you'll see it only ran 4 tests (while the other browsers run way more tests). There's a chance this artificially skews IE9's test scores up.

It's hard to reproduce the other scores from the benchmark (IE9 is certainly fast, though)... Chrome 8, 9 and 10 all put out a miserable 350 sprites by default on my machine, so I suspect he had to change some settings to get it to perform well. If only he had provided those settings along with his results, I could reproduce them.

Likewise, I cannot reproduce his Firefox results either - Firefox 4 manages around 1800 sprites on my machine. This is probably because he ran it under a VM - VMWare does a pretty good job of pretending to be a 3D accelerator, but it's not a real video card. I wouldn't be shocked if this negatively affected the performance of other browsers on the benchmark as well.

The difficulty of reproducing his results, along with how utterly bizarre the benchmark is - I need to compile node.js to run a canvas benchmark??? - makes me wonder whether it's of any value for actually measuring real-world performance.

Ultimately, though, an even more important factor is that this benchmark does nothing to measure the consistency of framerates - modern browsers can suffer from some pretty severe garbage collection pauses while running games and applications written in javascript. Even if your game is running at 60fps, if it pauses for 50ms every 5 seconds to collect garbage, it's going to be a pretty terrible experience. At present, both Firefox and Chrome suffer badly from garbage collection pauses in many browser-based applications, but this is not represented in most modern benchmarks.




I made two articles about optimizing my game Crajsh (http://www.crajsh.com). Avoiding GC pauses is possible right now but you have to put some effort into it.

http://blog.gamesfrommars.fr/2011/01/25/optimizing-crajsh-pa... http://blog.gamesfrommars.fr/2011/01/25/optimizing-crajsh-pa...

About the benchmarks: the maximum number of displayable sprites is not that a good measure. Performance of blitting would be better.


The GC issue deserves more light shed on it. Its a critical failure of most modern application environments. There may be hoops to jump through to ameliorate its effects, different on each platform.

Why not explicit language features? Animation is a niche but pretty important to many of us.


Running under VMware skewed the first results. We have been hustling to get the code to version 0.1 and I didn't get a comparable test PC in time. We will be rerunning all the benchmarks soon without VMware.

As for using node.js, we're starting to test various communication channels -- websocket versus long poll techniques versus straight ajax etc -- and it's faster for us to be working in a single project as we bootstrap up the tech curve.


Pretty sure Firefox disables hardware acceleration if run inside a VM.

In general, benchmarks run inside VMs are worthless.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: