Construct 3 icon

Construct 3


The debugger 'CPU profiler' tab

Published 14 Aug, 2017
713 words
~3-5 mins

Paid plans only The CPU profiler tab provides a more detailed breakdown of the estimated CPU usage. The game must be running continuously for the profiler to be able to collect and display information. It then displays a breakdown of the estimated CPU time spent in each part of the game logic. It updates once a second and the values shown are for the previous second only.

The CPU profiler tab displaying some resultsThe CPU profiler tab displaying some results

It must be noted that the overall CPU usage is an estimate to begin with, and all other values are therefore estimates as well. The details shown in the profiler only relate to the main JavaScript thread, and the CPU could be busy with other tasks, such as processing audio or running pathfinding calculations. Additionally the time for the GPU to render the game is not taken in to account at all by the profiler (and is instead covered in the GPU profiler tab).

Despite the above caveats, the profiler can be used to identify "hot spots" which would be good candidates to attempt to optimise first if there is a performance problem. For more performance advice, see Performance Tips. Note that optimisation is often not necessary and is a waste of time if the game is already running fast enough. For a deeper discussion of the subject, see the blog post Optimisation: don't waste your time.

Profiler breakdown

The profiler shows a table identifying how much CPU time has been spent in each part of the engine, down to individual event groups. It shows both the Self time, which is the time spent in just that item, as well as the Total time, which is the self time plus the time for any sub-items. The total time is mainly applicable for events, since it shows how much time was spent in that item and all its sub-items. For example an event group's self time is the time spent processing the group excluding any sub-groups, and its total time is the time spent processing the group including any sub-groups. By default the table is sorted showing the highest self time at the top, which is normally the best way to identify what needs to be optimised. However you can click the table headers to sort by total time instead.

The top-level items are:

  • Events: a breakdown of how much time was spent running event logic in the event sheets used by the layout. This is first broken down in to each event sheet (in case includes were used), and then further down in to groups and nested groups of events. This can help identify the most CPU-intensive events which you may want to optimise.
  • Triggers: some triggers, like On mouse clicked, run outside the normal event processing that happens every tick. These are not covered in the Events section, so are included under this item instead.
  • Plugin processing: how much time was spent updating plugins in the engine. Many plugins require a small amount of work to update them every tick, such as for Sprite to advance animations. If there are a large number of instances, this amount of work can become significant.
  • Behavior processing: how much time was spent updating behaviors in the engine. Many behaviors require some work every tick to process movement, collisions and so on. If there are a large number of instances, this amount of work can become significant.
  • Physics simulation: how much time has been spent processing the Physics behavior. Physics simulation can be very CPU-intensive. If this value is high, consider using fewer physics objects. Note since Physics is a behavior, this is a sub-item of Behavior processing.
  • Draw calls: how long it took the CPU to issue rendering calls, not including the time for the GPU to complete them. In some cases, rendering calls can be quite CPU intensive, especially when very large numbers of objects are on-screen. Some browsers also forward all draw calls to another thread to be processed in parallel, in which case the Draw calls measurement will likely be an underestimate.
  • Engine: the remaining time spent in Construct's runtime engine, which is the overall estimated CPU with the events, plugin/behavior processing, and draw calls times subtracted away. This covers the general runtime overhead.