What slows down geometry nodes?

I’ve been experimenting with geo nodes & build some warehouse racking.

The components are all very simple - however, something is really slowing this down… all components seen are made up of simply cubes.

Since I haven’t used nodes much, I’m not sure where the bottlenecks occur.

stats:

node-stats

Any help appreciated!

Hm, there’s nothing there that jumps out as particularly inefficient. What are your system specs?

There is a timing overlay you can use for debugging:

Thanks -

I’ve never heard of the timing overlay. How do we enable that?

System is"
Win 10
AMD Ryzen 9 5900X 12-Core Processor, 3701 Mhz, 12 Core(s), 24 Logical Processor(s)
TUF GAMING X570-PRO (WI-FI)
RAM 32.0 GB
NVIDIA GeForce RTX 3080

if you click on the overlay button on the top right you can find the overlays

1 Like

Got it. Everyting is <0.1 ms, except final geometry, which is .51.

Hmm…

Indeed with timing overlay you should get a clue of what’s going on…
Nothing seems particularly complicated… Maybe the slowdown comes from many nested instances.
You can try, even if that counter intuitive , to put a few realize instances node at some point in the tree and see if you get any speedup…
You need to test what is the right balance, so you keep some instancing, that is good , but avoid too many instance of instances of instances…

But maybe the issue is elsewhere …

2 Likes

Ok, well, this is strange, but I think maybe I’m not understanding timings.

I actually tried this a bit earlier but didn’t find anything that worked.
However, after you mentioned it, I tried again, figuring that I’d start at the end and work my way to the beginning.

First place I put one increased the timing to 11ms, but I can make LOTS of copies and everything is really fast and smooth…

hmmm…

timings

Ok that’s weird, but at least, if it works …

But wait … your issue was not in the execution time of the nodes… do you mean that before it was less than 11ms , but your issue was more on the viewport that was getting laggy ?

If that’s it, then it’s the way that instances are drawn that is not as fast as it could be. Especially because you had nested instances this makes the refresh a lot slower.
With the realize instance nodes, you convert instances to geometry, and that may makes the tree execution slower, but the viewport refresh may become faster.
The tree is only updated once ( unless you animate value), I think now that’s totally fine, 11ms is great !

Obviously that depends on the case , in general it’s better to keep instances …

So yeah, to sum up, the timing of the node is only about how much time it takes to create the geometry. not something like viewport fps. But of course , if the tree is animated , then the tree needs to be computed every frame.
But then , once the tree is executed in 11ms the geometry + instances are send to the viewport , and it’s the viewport ( workbench, eevee, cycles) that is in charge of rendering all that geometry as fast as possible. And with many instances that part can get slow.

1 Like

Yes - previously it said <.01 ms, but the display was REALLY laggy. I’m able to navigate the view very smoothly now, even with lots more objects on-screen.

1 Like

Ok awesome !

1 Like

blender does tend to slow down in viewport with more objects, I wonder if there is a similar slowdown with multiple internal objects inside of geonodes.

There are over 3600 objects all being instanced, and since the objects are just cubes, you aren’t gaining much performance by instancing them. The nested instantiation is probably causing some issues as well, since blender should be pretty performant with 3600 instances, but they are complex, branching instances, so that could be part of the problem.

2 Likes