Hi! Godot newbie here.

So in my Emeny.tscn I have this Area2D called PlayerDetection, when I want to add the signal of body_entered to a method with the node inspector (or whatever it is called)

a connection is added to the scene file:

[connection signal="body_entered" from="PlayerDetection" to="." method="_on_player_detection_body_entered"]

and a method is added to the script

func _on_player_detection_body_entered(body:Node2D):

I am wondering why the UI is doing this. Doesn't this cause a performance overhead instead of just adding it like so:

func _ready():
	$PlayerDetection.connect("body_entered", _on_player_detection_body_entered)

Also the latter is easier to read/maintain imo.

Is this some legacy stuff?

Thanks!

    owzim Why would it cause performance overhead?

    owzim both methods are right but I use/have used both and I have not seen any performance issues between the two, personally. And i test on an Intel NUC.

    Signals are relatively performant and almost never a bottleneck. It's not worth worrying about too much.

    I agree that adding signals in code is easier to maintain, but it's nice to have the other option. It can provide more script reusability, and it inverts the node dependency, which can be good or bad depending on what you're doing.

    • xyz replied to this.

      award It's curious how much people tend to be concerned with signal overheads. I'm not sure why that is.

      A signal connection memory footprint is in the ballpark of the size of one reference, so 8 bytes. The performance cost is equal to that of a regular function call. Using signals is just like calling regular functions. The overhead is - zero.

      As for which way of connecting is faster, I'd bet on one stored in the scene file. It's done by native code and there's no *.tscn parsing overhead in the final product because scene resources in the exported game are all in binary *.scn format.

      But all those eventual overheads are so minuscule that we could safely call them theoretical 🙂. A project could easily handle hundreds of thousands of signal connections without anybody ever noticing anything. If you don't believe me, try it out. A test is trivial to make.

      • Toxe replied to this.

        owzim Just measure it instead of guessing. A short benchmark should be simple to write.

        xyz As for which way of connecting is faster, I'd bet on one stored in the scene file. It's done by native code and there's no *.tscn parsing overhead in the final product because scene resources in the exported game are all in binary *.scn format.

        Yeah, I was just about to say something similar. I'd bet the scene solution is faster.

        But also, as you said, it doesn't really matter. Both will be fast enough. The real solution would be to pick the one that is the most readable or "natural" in a given situation. Sometimes it's connecting to signals by code, sometimes it's via the scene.