Hello! In this devlog I'll discuss benchmarking, but before that, a required update was needed. Be sure to update to the latest version!

The new version does a lot:

• A lot of minor and bigger stuff that improves performance.
• Prevents the behavior from taking the resources it should save.
• Improves the reinitialization of objects.
• Fixes family issues.
• Fixes hierarchy support.

Optimization

The topic of benchmarking and optimization as a whole is very controversial, since different setups and software will yield a lot of different results. 

I encourage everyone to make their own analysis on whether they really need Object Pooling. If you didn't know about object pooling, it is most likely because your project doesn't need it. 

If you were already searching on how to implement your own Object Pooling system, or really wanted to squeeze every single drop of performance out of your game, this behavior is for you.

Before continuing, I also encourage reading this article, as no truer words have been spoken: answer your own performance questions with measurements.

However, you came here to see some action, so let's see it.

Benchmarking

With the new update, a new demo project is included: performance-test.c3p. This project is the one I used for the benchmarking.

The project consists of an object with physics and two children being created repeatedly on a scenario made to force the object to interact in different ways to increase the physics usage.

The use of hierarchy is very intentional, an object with hierarchy is where you most likely want to put this behavior. Creating and destroying multiple objects at once, and each single object having one, two or more children, is something that will scale immensely, and where having an Object Pooling system is the best idea.

I started the simulation 6 different times. All with full-screen and debug mode enabled.

I tested it on three different power usage profiles from my computer, to limit the amount of RAM & CPU given to the game, once with the Pool behavior and one without it. And recorded everything:

Results

I extracted all the CPU usage from the start of each second (marked in the "Since:" line of text object), and compare each other on a Google Sheet you can access here.

Limited Performance

For the Balanced power usage profile, AKA "Limited Performance", at first there's not much to see. It seems like a ping-pong, where the CPU just happens to be faster in certain seconds on certain simulation just because.

However, the average tells another story:

Not a particularly groundbreaking story by itself, though. Only a 2% of improvement, and it may be a fluke.

Good Performance

For the Performance power usage profile, AKA "Good Performance", the results are clear as water:

Just from the start, we can see that the project with the Pool behavior, beats at almost every single second the project that doesn't use it.

It's to expect that a computer, with more RAM as its disposal, will better work with a system made specifically to maintain objects on memory.

We get a 4.4% increase. It may not seem a lot, but this, with the previous simulation, demonstrate that the behavior does improve CPU usage, and that by itself could scale greatly depending on your project.

Bad Performance

Taking into consideration the previous statement about RAM, and how a better computer will make the most of an object pooling system, I wondered if limiting it with the "Power Saver" profile, would actually turn the Pool behavior into something that slows down the project.

This was not the case.

Even though having a lot of objects on memory would appear counterproductive specifically on limited computers, at least on my simulation doesn't seem a problem. If the behavior doesn't decrease the CPU usage on your project, at least I'm certain it won't increase it.

Final thoughts

Object pooling is a practice proven by time and a lot of games and software. However, talking about this specific implementation for Construct 3, a lot is to be seen. 

Construct 3 games are as optimized as web technologies can be, however with my experiments and these results, although limited indeed, I'm happy to show that room for improvement can be made, to Construct and to your projects and games. 

Consider trying it by yourself if you're working with a bunch of instances, specially if they have hierarchies 😄! 

Thanks for reading!

- Master Pose