Learn how you can improve the performance of your game.

While Makinom is already optimized for performance, you can use additional tweaks and techniques to further improve your game’s performance. Naturally, this depends on how you’re using Makinom’s features and on other factors, like your target platform.

It’s recommended to use Unity’s profiler (Unity menu: Window > Profiler) to check which optimizations are beneficial for your game. Keep in mind that the profiler will also influence the outcome.


Creating objects (e.g. game objects or data holding structures) and freeing their memory after use is costly – preventing this through pooling can improve the performance of your game.

Pooling Game Objects

Instantiating and destroying game objects can decrease the performance of your game, especially when happening often. This can be reduced by using pooling.

It’s not a good idea to pool every game object – e.g. level architecture or other game objects that are only needed once in the scene. Pooling is only useful for game objects that are often used (instantiated and destroyed), like particle effects or bullets.

Pooling of game objects is set up in the Makinom editor (Base/Control > Game Object Pools). Learn more about pooling game objects in this how-to on pooling.

Pooling Lists

Lists are widely used in Makinom, e.g. changing and checking game variables often involves a list of the used variable handlers. Creating lists and freeing their used memory after use can also influence performance, particularly when done very often per frame.

Makinom automatically reuses lists where possible – i.e. once a list is no longer needed, it’ll be returned to a pool of lists and reused at another time. This improves performance, but also increases the required memory.

You can change the list pooling settings in the Makinom editor (Game > Game Settings > Performance Settings). To disable pooling, set the pool size of the individual lists to 0.

Use the Trim Excess option with caution  – while this frees the memory occupied by larger lists to reduce the total amount of allocated memory of your game, this will have an impact on performance if it happens often. Only use this option when you’re running into a problem with using too much memory (or reduce the number of pooled lists). Trim Excess is by default disabled.

Machines and Schematics

Starting schematics through machines or schematic nodes is optimized for fast and performant execution, but can still have a large impact on performance when starting a lot of machines at the same time (e.g. using a Start Machine node). While Makinom does a lot of optimizations under the hood, there are some things and settings to consider on your end to further improve the performance.

Please note that the influence of these tips on the performance largly depend on your use of Makinom’s features and your target platform. In a simple or light setup without many machines running at the same time, you’ll barely notice the improvements – but when starting/running hundreds or thousands of machines at the same time, you’ll notice the impact these settings can have.

Sharing Local Variables

When starting machines in a schematic using a Start Machine or Start Tagged Machine node, you can optionally share the local variables of the running schematic with the started schematics/machines. Unless there’s a reason not to do this (e.g. they’re using the same variable keys but you don’t want the started schematics to override the running schematic’s variables), it’s recommended to share the local variables. Otherwise each started machine would have their own variable handling, which impacts performance.

If none of the involved schematics use local variables, this can be ignored.

Sharing Local Selected Data

Like local variables, selected data lists of the running schematic can be shared with the started schematics/machines when using a Start Machine node. This also improves performance and is recommended, unless you don’t want the selected data to be shared (e.g. to prevent interference between the schematics).

If none of the involved schematics use selected data, this can be ignored.

Repeat Schematic Node

The Repeat Schematic node is very useful for schematics/machines that repeat execution every frame, e.g. Tick Machines or Auto Machines using Repeat Execution. Starting a machine is more costly than repeating a running schematic.

This node will repeat executing the running schematic from the start in the next frame (or FixedUpdate depending on the machine’s update type). This will perform far better than having a Tick Machine start the schematic each frame. If the machine should only run under certain conditions, you can use the Auto Stop settings in the machine component to stop the schematic when the conditions aren’t valid any longer. Additionally, you can use a Check Start Condition node in the schematic to check the machine’s starting conditions.

Single vs Multi

The Execution Type of a machine can also impact performance. Single execution will perform better than Multi execution, because Multi needs it’s own instance of the schematic for each simultaneously running machine.

If the used schematic doesn’t involve anything with time (e.g. a Wait node or waiting for a node to finish), all nodes will be executed within the same frame, making Multi execution not neccessary (because the schematic already finished executing before the next machine could start).

E.g. starting 1000 machines using a Start Machine node will perform far better with Single execution than it would with Multi execution.

The Blocking execution type is the same as single (but preventing other Blocking machines from executing).