Black Butterfly
Black Butterfly

Reputation: 35

Godot code optimization - calling a value from another node

Got a question regarding how it will be better to get values from another node within one function.

I have this piece of code, which multiple times getting same value from another node:

func locrestrict(transformX, transformY):
    self.transform.origin.x = clamp(transformX, -cam_node.cam_bounds.x - 1, cam_node.cam_bounds.x + 1)
    self.transform.origin.y = clamp(transformY, cam_node.cam_bounds.y - 1, -cam_node.cam_bounds.y * 2)
    if cam_node.translation != cam_node.cam_init:
        self.transform.origin.x = clamp(transformX,
            -cam_node.cam_bounds.x - 1 + (cam_node.translation.x - cam_node.cam_init.x),
            cam_node.cam_bounds.x + 1 + (cam_node.translation.x - cam_node.cam_init.x))
        self.transform.origin.y = clamp(transformY,
        cam_node.cam_bounds.y - 1 + (cam_node.translation.y - cam_node.cam_init.y),
        -cam_node.cam_bounds.y * 2 + (cam_node.translation.y - cam_node.cam_init.y))

Will Godot automatically use a same record from the memory for all these operations, or it will be better to var a temporary value at the start of the function to prevent multiple node calls?

Upvotes: 1

Views: 321

Answers (1)

Theraot
Theraot

Reputation: 40285

In Godot 3.x does not do any such optimizations. However, expect very little performance improvement. The reason being that in Godot 3.x GDScript is an interpreted language, and Godot still has to figure out what you are accessing (local variable or not).

I suggest you try the profiler to find out what functions are actually expensive in runtime and begin there. And while we are at it, don't take my word for it. If this function performance is important, try the optimization you have in mind, and see if it made any difference in the profiler.

In Godot 4.0 GDScript is compiled to a virtual machine. I don't know how smart the compiler is, or will be in the stable release of Godot 4.0.


I also want to say that optimization isn't always about doing things faster. Sometimes it is about doing less, or doing less frequently.

For instance, this function as is, probably isn't a performance issue, but if it has to run tens of thousands of times per frame, it might be.

It appears - I'm not sure I fully understand the code - you are implementing the functionality of drag_margin_* and limit_* properties of a Camera2D. If you can have the Camera2D do this for you, instead of writing it in GDScript, you will have better performance. This is an optimization by doing less.

Anyway, it appears the function at hand depends on a particular transform changing. If you have reason to believe it might not change every frame, then you might benefit from only calling this code when it does (e.g. using NOTIFICATION_TRANSFORM_CHANGED). See also How to invoke a function when changing position?. This is an optimization by doing less frequently.


By the way, speaking of optimizations. Typing your variables in Godot 3.x has virtually no impact, but does have it in Godot 4.0. I suggest to take it as good practice. In this case it appears the parameters should be float, and the method is void (does not return):

func locrestrict(transformX:float, transformY:float) -> void:
    # …

Otherwise you are defining them to be variant. And Godot has to figure out the type of what is stored in the variant every time.

Something that will have a more noticiable impact in performance in Godot 3.x is taking advantage of some types. In particular, consider using Vector2. If you can take advantages of vectors to operate on multiple values in less instructions, it means Godot needs to interpret less instruction to archive the same result, and thus better performance. This is an optimization by doing less.


GDQuest has a few articles about GDScript that you may find useful (they did expend some time figuring what actually works):

Note: Even though the term "type hints" stuck, they are actual type declarations.


You may also consider using C# or even C++ as avenues of optimization for the critical parts of your code. GDScript is a great glue language, and also great prototyping language. Yet there is value is porting expensive computations to another language. This would be an optimization by doing things faster. Although I won't consider the code in the question to be an expensive computation.

Upvotes: 1

Related Questions