How to analysis the Performance difference when add the input function to different place?

origami

It is the game I make a pretty simple type game, a lot of letters falls down, and you type the correct key to dismiss them. Which use the basic frame of Dodge the creep from tutorial.

Here is the files in my project, you can see the main and mob scene. mob scene is the fall down letters. And in main scene create the instance of mob.

For detecting the key press in this game. I get two ways to make it: 1. I can put the _input function in MainScene then send the signal to mobs(keys), write code in main.gd file. 2. Or put the _input function in MobScene and detect the key press in each mob(key) instances itself, write code in mob.gd file.

I wonder is there a big difference in performance? And how to check it?

Zireael

I assume there is no difference, or it is negligible. Especially for a 2D project, Godot is bleeping fast.

If you want to check, just do one, check FPS in the monitor, do the other, check FPS in the monitor tab...

solstice-projekt

Using the FPS monitor will not yield anything of value.

To measure performance, do ...

usec = OS.get_ticks_usec()   # In Godot4: Time.get_ticks_usec()

# do stuff you wish to time here

print(OS.get_ticks_usec() - usec) # Prints the time spent, in microseconds.

Regardless, this isn't going to help much with the OP's question.

Your use case does not warrant caring about the performance, even ten years ago.

Still, because you want to learn, consider that every extra code in every node adds at least one call to that specific routine.

Consider that signals are nothing but extra code executed at the end of the frame, unless specifically specified otherwise using the DEFERRED flag.

Each Signal adds yet another call to the chain.

Personally, I do all my input in the main script and update coordinates of objects in threads, instead of having my code fragmented all over the place between nodes. That, again, is overkill for your use case of course, so it depends on what you're more comfortable with.

When you want to handle tens of thousands of things, then all these calls are pure waste. In your specific case it doesn't matter, though.

I hope this was helpful.

Zireael

Time in microseconds is really unnecessary for the kind of "performance" the OP wants to analyse, though, exactly because of this: "Your use case does not warrant caring about the performance, even ten years ago."

I do most of my "performance" improvements just by looking at the FPS, because in the end, FPS is what your players will care about.

Calinou

I do most of my "performance" improvements just by looking at the FPS, because in the end, FPS is what your players will care about.

Frame time (in milliseconds per frame) is a better measurement than FPS, as FPS is not linear while frame time is. Most AAA developers optimize in terms of frame time (also called frame budget) rather than FPS :)

For example, the difference in frame time between 120 FPS and 90 FPS is not the same as the difference between 90 FPS and 60 FPS.

cybereality

If you're talking about the difference in a 2D game with 12 blocks, I doubt it would be measurable at all. In theory, handling everything in a main script should be faster, particularly if you have hundreds or thousands of objects, and there is some sort of complex code that is happening. But if you are simply reading a key press and adding an int to a score variable (or removing the block) and can't imagine there would be any problem at all either way.

You don't want to optimize prematurely. Especially not if it is a simple 2D game that can run at 300 fps on an Intel integrated GPU, it's a waste of time. Sure, maybe it could run at 310 fps (on Intel) or 3100 fps on an Nvidia card, but it's well above the refresh rate of the monitor and will make absolutely zero difference to the player experience, while making your code harder to write, harder to maintain, and in general wasting your time investigating things that don't matter.

I mean, yes, if you were trying to make GTA 6 in Godot, then by all means you will need to optimize. But I would still recommend writing your code the simple and obvious way first, and then refactoring if and when it is a problem. I think they said that 20% of the code accounts for 80% of the performance problems (or something like that). So if you try to optimize 100% of your code, 80% of that time and effort is wasted. Better to get it working, profile, and then discover what the 10% or 20% of the code that is problematic, and verified to be problematic, is, and then optimize just that.