All Questions

Community

W
Edmond WU(edmondwu1022)

Why define var inside _physic_process

Hi Nathan, 

one quick question, as I understand that _physic_process (or _process) is update on eveyframe, if we define "velocity" inside. is that mean it will repeats to define "velocity" everytime when the frame updated?

does it effect the performance?

  • Nathan Lovato replied

    In short, this is negligible when it comes to performance. You'll find some more insights below.

    Why use local variables

    You use locally scoped variables to avoid exposing them and, as your code complexity grows, avoid changing variables in unexpected ways, which is the source of so many bugs in computer programs.

    A lot of the way we show you how to code has more to do with keeping your code readable, flexible, or bug-free if possible than making it fast.

    Performance impact

    Most of the time, this has a negligible impact on performance. That is, even now with GDScript that has little to no optimizations, like Python (at least the version you download on python.org).

    This is because the really heavy operations, the loops that do thousands of things every frame happen inside the Godot engine, through code you call from GDScript. And that code is written in fast, compiled C++.

    How to know if something matters for performance

    The key rule about performance is it's something you must measure in your game. If the game slows down or you measure a given function call takes a lot of calculation time, then you have something impacting performance.

    If, however, the game always runs at 60 FPS, you don't have a problem.

    There's a tool built into Godot to measure performance: the profiler.

    We wrote a guide on Godot's profiler: https://www.gdquest.com/tutorial/godot/gdscript/optimization-measure/

    Here's another guide about leveraging Godot's built-in code for performance: https://www.gdquest.com/tutorial/godot/gdscript/optimization-engine/

  • Nathan Lovato replied

    There's no garbage collector in GDScript so no issue in that regard.

    its kinda common sense in dev yeah so why do differently?

    I don't think there's a common-sense or best practice that holds true across programming languages regarding the scope of your variables.

    In Python, for instance, a garbage-collected language by default, people tend to use local variables as much as possible for readability, and, same as I explained above, to limit unwanted access. Unexpected changes in variables being the primary source of bugs in code - the smaller your variables' scope, the less unexpected accesses you risk.

    Also, performance-wise, in Python, local variables offer the fastest lookup speed for the compiler so you can't really say global variables lead to faster programs than local ones. However, you can say for sure they lead to more bugs.

    GDScript works a bit similar, without the garbage collector.

    In languages like javascript, the compiler will change your code in ways you may not expect so you can favor local variables and limit their scope + improve readability (keep code localized).

    Note that here, to me, we're discussing a really small detail in any case.

     I'm seeing a lot of inconsistencies and issues with Godot 2D Secrets that make me wonder...

    What are the many inconsistencies and issues you found? 

  • Fluxpunk replied

    My apologies, I just read the Design Patterns in Godot lesson and learned GDScript is not a garbage collector language. Realized I'm being and idiot jumping to conclusions sorry! Deleted my comment.


    I'll now reserve my feedback for until I complete the course. I'm happy to be supporting such a project, and thank you for your response!

  • Nathan Lovato replied

    By any means, if you have questions or concerns, please go ahead and ask. Feedback's also welcome anytime. In gamedev in general, in Godot, and at GDQuest in particular, we do things in certain ways and it's not always clear why - so it's natural for us to explain as needed.