Forums » Code » How to Get Over 5000 Entities Onscreen

I created a particle performance test comparing Canvas vs. DOM vs. WebGL vs. ImpactJS vs. PixiJS. The results are illuminating. Using several tricks, I'm able to push ~10k entities at 30 FPS with ImpactJS on my laptop. I hoping this will help other devs in optimizing their games and benchmarking the various web technologies.

Best.

10k entities at what fps? At 10k I'm only getting around 15fps on my desktop. Still comparing the two benchmarks it does have marked improvement. Nice work. I've yet to dig into the code.

30fps. My laptop is fairly new, so performance will vary.

15K at 37fps ... whats the performance liek on phones?

Added PixiJS test.

Holy crapamoly PixiJS and WebGL blow everything else away.

Nice improvement in ImpactJS fast.

When you say "expensive closures"... multiple closures at all? Or the specific Resig-Class-parent stuff? What led you down this particular path? Were you profiling? What took the most time?

I'm not a fan of the Resig-Class stuff but mostly from a JS purist point of view. Adding performance concerns on top would just be icing in future arguments. ( =

I think closures are a JS framework's main extensibility point, but maybe there's some post-processing you could do to speed things up after things settle down..?

Here's a pic of ImpactJS Memory Usage. Here's a pic of Canvas Memory Usage. Both of these were taken with 1500 particles onscreen.

As you can see, Impact creates an erratic amount of garbage, whereas the Canvas implementation creates a limit amount of garbage.

Every Javascript function call requires a new scope to be created. Using closures doubles the number of function calls (one for the closure and one for the function itself). Impact makes heavy use of closures, and makes heavy use of functional calls in general. The Impact API is well-written and strives to achieve separation of concerns; but unfortunately, with Javascript, it comes with a price.

Is the impact fast using the web gl renderer, if not, would that be possible, it would be great to know what the perfromance of impact + web gl is like compared to standard web gl or standard impact...

Only Pixi and WebGL use WebGL. Impact-Fast is canvas and Impact. I commented the code heavily, so dive in and take a look!

will do, trying to get out of beta and onto the app store though this week (or next!)

ill try and plug this into your demoes:

http://blog.hiive.com/2011/07/accelerating-impactjs-with-webgl.html

I updated my repo with a DOM test and two new WebGL tests. I'm now able to push a million particles at ~12 fps on my laptop.

Yipe!

If I understand this right, one of the major performance improvements you've made is to strip function calls and merge the code that was in those individual functions into a single function?

The performance improvements are great, but it makes for code that is very difficult to extend or build on top of. What if instead, to keep our classes and code modular and easy to use, we modified the ImpactJS bake/build method to do this automatically for any class? For example, any time a class extends something else, we look for all "this.parent()" calls, then replace that with the code from the parent class' function?

I'd expect modern browsers could do their own optimizations for basic prototype function calls, but maybe the "this.parent()" call is problematic?

Take a look at the Two small improvements to ig.Class thread in the Private forum. Yes, the parent closures are an issue. My advice would be to pull out any hot Entities and have them not extend ig.Class (build in the necessary properties into a generic object).

Thanks for pointing that out quidmonkey, great information there!

Two very useful forum posts, thanks!

Hey, just had a thought quidmonkey: in Chrome, can you grab a heap profile of your demos, one without these improvements and one with and let us know?

Just wondering how much garbage is getting created with the existing inheritance scheme and all those closures vs. streamlining the inheritance chains, y'know?

If you don't, I will... but having a toddler makes it kinda hard to dependably do perf testing in my off hours. ( =

Really awesome work all the way around.

Quote from drhayes
Hey, just had a thought quidmonkey: in Chrome, can you grab a heap profile of your demos, one without these improvements and one with and let us know?

Just wondering how much garbage is getting created with the existing inheritance scheme and all those closures vs. streamlining the inheritance chains, y'know?

If you don't, I will... but having a toddler makes it kinda hard to dependably do perf testing in my off hours. ( =

Really awesome work all the way around.

Thanks for the kind words. You can see a couple of screenshots from a profile I did in a post above:

Quote from quidmonkey
Here's a pic of ImpactJS Memory Usage. Here's a pic of Canvas Memory Usage. Both of these were taken with 1500 particles onscreen.

There's a pixi.js plugin here for impact...


https://github.com/ekelokorpi/impact-pixi

sprites:
http://kelokorpi.com/impactpixi/example/


spline:
http://kelokorpi.com/impactpixi/spine/

render to texture (not impact!)
http://www.goodboydigital.com/pixijs/examples/11/

Yea... that's interesting (the pixijs plugin). The example doesn't use a standard impact entity though even though the plugin looks like it has injects for it.

this branch works with pixi/js for ejecta .. now to get impact/pixi/js and try and do some tests on devices .. if i can..

https://github.com/GoodBoyDigital/pixi.js/pull/97

It would be amazing if the Pixi plugin was made so simple that all you had to do was require it and it would automatically determine the best draw method and use it. The "usage" setup steps seem unnecessary.

For example, having to load assets with ig.Asset()... Why not just overload the default Impact classes like ig.Image so that it happens in the background. I don't need to know about it do I?

This is likely because the plugin needs to create/preload GL textures.