Performance Zone is brought to you in partnership with:

I’ve been a Windows developer since 3.0 and caught the Visual Basic wave early with v1. I’ve released a “production” application in every version of VB since then (except VB for DOS). Focusing on enterprise, line-of-business development I’ve built Call Center Applications, Mortgage finance systems, Customer Relationship Management tools and more recently I’ve been in the Litigation Support/Electronic Data Discovery/Electronically Stored Information space. Greg is a DZone MVB and is not an employee of DZone and has posted 470 posts at DZone. You can read more from them at their website. View Full User Profile

Making High-Performance, Garbage-Collector-Friendly JavaScript

08.07.2012
| 4691 views |
  • submit to reddit

Everyone is JS'ing these days, so making sure you GC well means your VM will have a high IO! :P

The following excerpt is from "High-Performance, Garbage-Collector-Friendly Code," by Martin Wells.

16 milliseconds is not a lot of time. Try eating a hotdog that fast – though I swear I’ve seen our dog go through a beef sausage in under 100 milliseconds.

If you want your game to run at 60 frames per second, 16 milliseconds is all you have to get everything done: moving bullets around, creating new entities, drawing sprites, checking collisions, tracking and changing states, handling input and playing sound. Whatever happens regularly in the main game cycle needs to operate as efficiently as possible. Even at a lower-performing frame rate of 30 per second, you’ll still only have 32 milliseconds to get everything done. Speed and efficiency are important, and that importance increases over time as you add more things to your game.

What’s garbage collection, and why do I care?

If you’re developing a game that has many things happening at the same time, say a weapon that fires missiles 5 times per second – not an unreasonable weapon fire rate for a high-speed shooter – you’ll quickly discover that one area of substantial impact to performance is object construction and subsequent garbage collection.

As your classes grow in size, and possibly in complexity, you’ll begin to notice lag introduced when you construct something new; this is exacerbated if you’re doing complex setup of sprites and sounds (even if they are cached in static resources). Creating lots of objects also has the side effect of generating garbage collection.

For those new to the concept, JavaScript, like many other interpreted languages, frees you from having to manage memory; you can create objects at will, without really having to keep track. The browser (or to be more specific, the JavaScript Virtual Machine running inside the browser) will come along periodically and clean up anything you’re not using anymore. This part of the system is the garbage collector (GC) – you can think of it like the ultimate housemaid.

Depending on the browser, and number of objects you have in use, the process of garbage collection can take anywhere from 10ms to 2000ms. The more things it has to check to be cleaned, and the more cleaning it has to do, the longer it will take. If you’re writing a game with independently moving objects, like an action game, this pause is going to at best noticeable, or, at worst, a series of frustrating stalls that kills the experience.

Garbage-collector-friendly code

For the most part, it’s pretty easy to write code that makes life easy for the garbage collector . . .

- Martin Wells

Published at DZone with permission of Greg Duncan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)