Precompiled Data

Precompiling is what a node does with a blueprint before it runs it: it prepares the blueprint's structure once and keeps it in memory until the next save. This page explains what that prepared copy holds, when it is refreshed, and what the green 'fast' icon on a simulated value means.

A node prepares each blueprint once and keeps it in memory

The first time a node runs a blueprint, it loads the blueprint's blocks and wires and prepares them for running. The node keeps that prepared copy in memory, and every later run on that node starts from it instead of loading the blueprint again.

It holds structure, not values. No block output is kept between runs. Every run computes its own values, and within one run a data block is computed at most once however many blocks read it.
It is per node. Every node of the cluster prepares its own copy the first time it runs the blueprint.
It does not expire. There is no idle timeout: a precompiled blueprint stays in memory until a save refreshes it or the node restarts.

A save refreshes it on every node

Saving a blueprint refreshes the precompiled copy on every node of the cluster: the next run on each node prepares the saved version. Runs switch from the complete previous version to the complete new version, so a run never sees a half-saved blueprint.

The first run on each node after a save therefore pays for loading and preparing the blueprint; later runs do not. The Precompiled cache miss chart on the cluster's usage page counts how often that happened.

The green icon marks a value this run computed

In a simulation the Studio prints each out-pin's value beside its block, and marks the values the run computed or received as input with a green icon. It is not a value stored from an earlier execution: block values are not kept between runs.

What makes a blueprint faster

Reading a data block from several places costs nothing extra: it is computed once per run.
Data nobody reads, and blocks on a branch that did not run, are never computed.
Storage queries, external calls and loops are where time goes. Cache what you read often, keep array_map and foreach callbacks short, and move slow work to the queue.
When calling a function, a modal or a queue item, pass only what it needs, for example just the guid instead of an entire object.

Block Execution The order blocks run in, when data blocks are computed, and how errors are reported. Common Pitfalls Caching, aggregations and the other mistakes that cost the most time.

Frequently asked

What does the green fast icon on a simulated value mean in RUAL?

In a simulation the Studio prints each out-pin value beside its block and marks the values this run computed or received with a green icon. It is not a value stored from an earlier execution: block values are not kept between runs.

When does RUAL recompile a blueprint?

After a save. A save refreshes the prepared blueprint on every node, and the next run on each node prepares it again. Runs switch from the complete previous version to the complete new one and never see a half-saved blueprint. A prepared blueprint has no idle expiry: it stays in the node's memory until a save refreshes it or the node restarts.

How do I make my RUAL blueprint faster?

Cut I/O first: fewer storage searches and external calls, and cache what you read often. Keep callbacks of array_map and foreach blocks short, because every block in them runs once per item, and move slow work to the queue. A data block runs once per run however many blocks read it, and data nobody reads is never computed.