The Block End Compile works in concert with the Block Begin Compile to separate part of a node network from the rest of the graph.
When this node cooks, rather than cooking its inputs traditionally,it only cooks the inputs of its corresponding Block End Begin nodes. After acquiring that data, the rest of the nodes are executed as a single operation. Certain optimizations are possible since this execution of the compiled block is done outside of normal node cooking. Most notable is that any gather-based for loop can be run in parallel.
The nodes do not gain any cached data so the intermediate results are not available (and may not exist in some cases) because the nodes in the block are not individually cooked,
Displaying the intermediate nodes will use the normal cook approach, allowing their equivalent content to be viewed. This also means all errors and warnings are reported on the final node.
This node will rarely be explicitly placed. Instead, the Compile Block tab menu entry will generate a pair of block nodes in a single operation.
Controls if the input nodes will be executed as a compiled block. Disabling through this toggle is a quick way to compare compiled and non-compiled behavior.
This node, as part of its own cache, may store the cached states of the nodes in the block. After execution this intermediate data may be unloaded, requiring additional re-cooking if results need to be re-used. Since compiled blocks are usually built for non-cached sections of the node graph, this defaults to always.
By unloading the inputs, it also increases the chance that successive nodes in a chain can re-use the same geometry, avoiding potentially expensive copy operations.
The topology of the subgraph connected to the node is cached. Dependencies are created to ensure this is rebuilt whenever the input nodes change, but if necessary this button will clear the cached network and force a recompile. This can also be useful for re-generating compile errors when this node is not displayed.