I've been reading up on getting and finding nodes (https://docs.godotengine.org/en/3.1/classes/class_node.html#class-node-method-get-node) Are there and speed\efficiency concerns that I should know about?

For example: Which is faster get_node("NodeName") or find_node("Node_Name") or child_node(2)? When should I set "recursive" to false? Which is faster, doing a full root path, or iterating around(e.g. get_parent.find_node("sibling_name") or get_tree().get_root().get_node("Root/Parent/sibling_name") or (get_node("../sibling_name/")

I'm looking for some best practices or situations I should try to avoid because they are known to be slower. I realize I could write my own timing programs to figure out, but thought I'd ask the community first to see if anyone already knows.

Thanks!

You should avoid using any of them.

As much as possible you should be looking up references to nodes on ready in which case look them up any way you like. They aren't that slow but they are slow if you're looking them up every frame.

Signals are another good way to avoid needing to look up nodes.

@Kequc said: You should avoid using any of them.

As a programmer by day, I'd already done that instinctively. But it is good to know that they are all slow lookups and should keep them out of loops. Are they all equally slow, though?

I have not tested so please table this with a grain of salt, but as far as I know, performance for node retrieval functions is something like the following:

  • get_child
  • get_node (Shorthand: $)
  • get_node_or_null
  • get_children
  • find_node

(The top item is fastest, bottom is slowest)

That seems to be the order in my experience, though I try to cache my node retrieval code whenever possible, so I have not really had any performance issues relating to node retrieval (or none that I remember).

I would say that so long as you are not getting retrieving several dozen nodes every frame and/or have limited CPU process to work with, which function you use shouldn’t matter too much as they are all relatively close to each other performance-wise.

3 years later