Hum, I thought it was the opposite, I also think that GN tries it’s best to run computations in parallel.
I would be super grateful if someone is willing to shed some light about how GN works in that matter !
Here is what I know : optimizations are a key point in GN development, a lot of decisions and improvements are made to favor performance even when processing a lot of geometry.
The only thing that can slow things down is the repeat zone that in fact can’t run it’s computation in parallel…
But it’s true that we don’t have control over how things are processed…
If optimization is really a concern you should definitely run some tests when building your projects, it’s hard to come up with universal rules… Basically you should see what is computation heavy in your trees and replace these parts with faster algorithms… Some nodes are heavy by default like raycast or booleans, but it also really goes down to how you’re using them…
Also, it might be worth splitting your scene in several objects so each objects can be evaluated in parallel. I suspect that say 10 objects with their own modifiers would probably be evaluated faster than a giant nodetree containing these 10 elements altogether… But I never took the time to investigate that indeed !
Lastly, I would also separate what is evaluated once and what is moving.
If you don’t have a scene time node or evaluate something animated then the modifier will be evaluated only once, therefore the execution time of the tree isn’t that much of a concern since it will be build when you open the blend or change a parameter but the scene will stay smooth otherwise.
Everything that is time dependent should be put on it’s own object and highly optimized if viewport playback is a concern…
Keep in mind that we also have the bake node now that can help to avoid extra re-computations or to bake initial parts of the tree…
Now that eevee support displacement some stuff can be moved to shader instead of geometry node: it’s very likely that folliage or grass can be animated in the shader rather than in geometry node so you can keep great FPS and evaluate that geometry only once…
Finally keep in mind that multithreading isn’t always the solution, sometime it’s faster to run every computation at once when they are very fast to compute rather than splitting them and waiting of every thread to finish…
To conclude, here is a bit of stats with my procedural castle scene…
The whole scene takes ~19s to build (looking at the evaluation time of the modifiers) , keep in mind that everything is generated from GN there isn’t any geometry except the basemeshes that are basically 4 cubes.
You can see the polycount on the screen capture :
I also added a few closer view so it’s easier to see the level of detail and how much geometry is processed :
This is how my system monitor looks like during the generation :
At this stage, I’m not that much annoyed by the time it takes to generate the mesh, which I found quite nice especially since I didn’t tried to make the scene super optimized either, but rather finding a good balance so I can work. But in fact it’s more the viewport that is getting pretty slow, probably because of the 500 000 instances lying around…
But that’s just me
To circumvent that issue I have a preview mode with simpler geometry that I can use to layout the scene and switch to final for renders…