Josh Goldberg
Screenshot of a Chrome devtools performance profile

How lazily instantiated classes reduced my game engines' reset times by half

Oct 9, 20175 minute read

Using lazily instantiated, dynamic classes instead of hand-written functions to reduce unnecessary work during loads.

A very long time ago, I made the decision to write my own game engine from scratch. If you want to get anything done well or in a reasonable amount of time it’s a terrible idea, but it does serve as a great vehicle for exploring best practices in performance-critical code.

One area of interest is how to describe large numbers of in-game object classes. I wanted to be able to add a class and its properties with as little code overhead as possible to avoid huge source files and maintenance difficulties.

My solution was a module called ObjectMakr that stores the inheritance tree for classes and descriptions of each of their properties as POJOs (Plain Old JavaScript Objects). It then would create a class for each POJO description and extend as described in the inheritance tree.

The Problem

Startup performance was bad under this system. Well over half of the reset time was spent in ObjectMakr’s instantiation. Using this screenshot of a captured performance profile, can you guess why?

In its original design, ObjectMakr processed all class functions immediately. That’s the big green chunk in the center. We’re talking hundreds of dynamically generated class objects all being created and assigned properties before the game can do anything. Terrible!

The Change

Important performance protip: minimize unused work. Out of those hundreds of objects, maybe a couple dozen would be used immediately. I changed ObjectMakr to only instantiate classes as needed, and voila! Reset performance was suddenly much better.

Lessons Learned

Use only what you need.

Laziness is good. When designing startup flows, I like to think of each application component as a node in a directed acyclic graph (DAG). If you map out the components this way and do an exhaustive search starting from the “everything is ready!” state, you’ll notice which parts are or aren’t required to get there.

Probably don’t write your own game engine.

On the one hand, I’ve learned a ton from it and have an intimate knowledge of all its ins and outs. On the other hand, there are plenty of great open source alternatives for every popular platform yet I’ve sunk way too much time into this thing. Were the learnings worth the time investment? Great question.

By the way, I have multiple game engine versions. The title doesn’t have a typo!

Liked this post? Thanks! Let the world know: