In this article we are going to introduce you to a much sought after feature that has been added to the new Debug Module in the 1.3 version of GameMaker: Studio - Profiling! If you are unfamiliar with the term, profiling is simply a way of checking a games performance while running, whether its checking the overall engine performance for bottlenecks, or checking individual functions to see which one is faster to use.
NOTE: This article assumes you are already familiar with the GameMaker: Studio Debug Module, but if you are not then you can find further information here.
Start Profiling!
To profile your games, you need to first start your game in Debug mode and then in the Debug Module, create a new window and select "Profile" for the window type. You will then be presented with something like this (although it will be empty of data to start with):
This is your profile window, and by default it will start off empty, since you haven't actually started the profiler yet. To start it up, simply click the button on the top left (it will be grey when disabled, red when enabled) and the debug module will start to display profile information for your game.
So what information is shown here? Well, you have on the left the various profile nodes. A node can be either an event, a script or a single function when in GML view, while in Engine view it will show the different calls to the GameMaker: Studio engine itself. These two different views can be changed by clicking the View Selector on the right of the window, and you also have the extra option of displaying them both at once, in which case the Engine calls will be coloured differently to help distinguish them from the GML calls.
Beside the target option, you can also select how the node data is to be viewed. The two options you can use are the Tree view, or the Bottom Up view:
Tree - This is a "top down" approach to showing the data, where the top tier of the node is the parent call, with further calls shown as children (you can click the (+) beside a node to expand it). So the top tier parent would be an event, with the children being script or function calls.
Bottom Up - As you can imagine, this is the opposite of the Tree view, where you are shown the child nodes, and clicking the (+) will expand the node to show the parent nodes (ie: what the function was called by).
You have one final option at the top of the window, marked by the "t" icon. Clicking this will toggle the way the data is displayed, with it showing either the average time and the average calls for a node, or the total time and calls for the node.
Interpreting The Data
The data that the profiler gives is presented in various columns, and you can click the column title to sort the data from lowest to highest, or alphabetically (depending on the column selected). The name column is the name of the node being profiled, while the time will show either the total time that this node has required since you started the profiler, or the average time that the node requires each step (times are in microseconds). The calls column is the same, with it showing either the total calls to the node, or the average calls. The final column, step %, gives you the percentage of a single step that the calls to the node have used up.
When checking this data, the first thing you'll probably want to look at is the step % column as that will show any immediate issues that you may have. When using the Engine view, you'll normally find that the Draw Room engine call uses most of this, which is normal, but should any other call be using a high percentage then you may wish to investigate and see why. So you would switch to the GML target, and have a look at both the tree and the bottom up percentages. The tree view will give you an idea of what actual events are eating up your step, while the bottom up view will show you the functions themselves that are using more processor time.
Summary
With this new tool in your arsenal you can get a detailed look at how your games actually perform at a granular level, and you can also use it to benchmark specific functions or your own scripts to optimise things. Want to know if it's quicker to use distance-to_point or distance_to_object? Well now you can easily find out... Is your games FPS low and you don't know why? Fire up the debug module and check the engine profile to find where the bottleneck is!
However, it's worth noting that while this is a fantastic tool, you shouldn't go all out and try to micro-optimise everything! Check your real FPS to see how your game performs on your target platforms and if it's doing okay and has some breathing space between the real FPS and the room speed, don't worry too much and only use the profiler when you see your game has issues - like FPS spikes, lagging, stutter etc... - or to get a general overview of performance while developing and so spot and avoid issues before they cause you a problem.