HTML and CSS Reference
In-Depth Information
In Chrome, the Profiles tab also has two other profile snapshots: CSS selector profile and Heap profile. The
former isn't likely going to be that useful in HTML5 game development because most lookups are generally
by IDs, but the heap snapshot can be useful. If you run into memory problems, you most likely have a memory
leak caused by not removing all the references to objects that are no longer used. Taking a heap snapshot shows
you the memory size of DOM and JavaScript objects at a specific time.
Play your game for a bit and then take a heap snapshot, and you should detect any anomalies. For example,
if you play your game for a while, take a snapshot, and then sort by the number of objects in descending order
by clicking the pound sign (#) and notice that you have 2,000 sprite objects hanging around; you most likely
aren't getting rid of sprites correctly when they die. Also keep a lookout for objects that balloon to sizes larger
than expected because this most likely means they keep more data around than they probably intend.
Two of the other tabs, Timelines and Auditing, can be useful for debugging web-page performance problems,
but they don't help terribly much in game optimization, so they aren't covered here.
Actually Optimizing Your Game
With all these tools at your disposal, the next question on your mind is most likely “How do I actually optimize
my game?” The answer, as you might expect, is “It depends.” It depends on the browser you use and what you
want to do.
The first step is to figure out where you might benefit from some optimization. Profiling, as discussed earlier,
is a good place to start. Both CPU profile and heap snapshots can help you pinpoint where you might want to
target your efforts—the former because it can tell you spots in the code that take a lot of time and the latter
because it can give you an idea of what types of objects you create a lot of. Optimizing objects of which there
are thousands is a good place to start.
Next, with the code that could use some help, take a look to see if there are either algorithmic changes that
could help or syntax changes that might improve performance. JavaScript is a flexible language, and some-
times that flexibility is used to the detriment of performance. Sometimes things that seem like they might be
performant actually end up costing CPU cycles. Unlike other languages, such as C, where you can examine the
resultant Assembly code to see how the compiler thinks the code should be run, the only way to figure this out
in JavaScript is to write a test and test that code across different browsers.
Now take a simple example of three different ways to create objects (see
Listing 7-1
):
Listing 7-1:
Object creation methods
var Obj1 = function() {}
Obj1.prototype.yay = function(x) {};
Obj1.prototype.boo = function(y) {};
var Obj2 = function() {
this.yay = function(x) {};
this.boo = function(y) {};
}
var Obj3 = function() {
function yay(x) {};
function boo(y) {};
return {
yay: yay,
