Making it faster
Practical levers to keep your graph responsive — freeze the heavy stuff, preview small, and stay procedural until you actually need pixels.
DNA recooks only what changed. If you tweak one parameter, most of the graph stays cached and only the affected nodes recompute. So the first rule of speed is: help the cache help you. The rest of this page is the handful of moves that make the biggest difference.
Freeze the expensive nodes
If a node's result isn't changing — a heavy simulation you've dialed in, a one-time scatter, an imported mesh — stop it from recooking. Set its cook policy so it holds its last result instead of recomputing every frame.
This is the single biggest lever. A frozen node costs nothing; everything downstream still updates around it.
Anything time-driven (a simulation.particle sim, input.video, noise that animates) recooks whenever the playhead moves. If you only need one moment of it, freeze it on the frame you like and keep working.
See Cook policy for the full set of policies and how to choose.
Preview small, render big
You don't need full output resolution while you're building. Drop the preview resolution in the The viewport and your GPU does a fraction of the work per frame. When you're ready to ship, the export still renders at full size — see Video & image export.
The same idea applies to counts: rough in a sop.scatter or a particle sim with a low count, get the look right, then turn the count up at the end. Most simulations cost scales directly with how many elements you're solving.
Stay procedural until you need pixels
DNA has two broad kinds of cost:
Procedural / shape data — points, curves, Analytic shapes, Distance Fields. These are cheap to edit and stay resolution-independent. An Analytic shape is described by maths, not pixels, so it stays crisp at any zoom and costs little to change.
Pixels — the moment you rasterize to a Raster, render a Volume, or bake a Field, you're committing to a fixed grid that has to be recomputed when it changes.
Keep your work in the cheap, procedural world as long as you can, and only convert to pixels near the end of the chain.
Baking a field once (instead of re-evaluating it live every frame) can be a big win when many nodes downstream sample the same field. Bake it, then everyone reads the cached grid. See Fields & sampling.
GPU-bound vs CPU-bound
Knowing which one you're hitting tells you what to cut.
GPU-bound (the usual case): high preview resolution, large volumes, heavy rasterizing, many lights, big particle counts. Fixes: lower resolution, reduce counts, simplify materials, bake.
CPU-bound: large Collections processed element-by-element, heavy Expression logic on big point counts, importing/parsing big files every frame.
The The performance panel shows you where the time is going so you're not guessing. Open it, find the slow node, then apply the matching lever above.
The first time a new effect appears it may stutter for a frame while DNA compiles the shader behind it. That's a one-time cost — it runs smoothly from then on, and the compiled result is remembered between sessions.
A quick checklist
When a graph feels sluggish:
Open the The performance panel and find the heaviest node.
If its result is static, freeze it with a cook policy.
Lower preview resolution and rough in counts low.
Move any pixel conversion (rasterize / render / bake) as late in the chain as possible.
Bake fields that many nodes sample.
Bypass branches you're not looking at right now.