this post was submitted on 22 Jun 2024
32 points (100.0% liked)

Godot

6016 readers
177 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
32
Where have you suffered some performance penalties using GDScript, and what was the fix? Was it to rewrite it in C#? (docs.godotengine.org)
submitted 6 months ago by [email protected] to c/[email protected]
6 comments fedilink hide all child comments
 

I'm curious because GDScript sounds like a very high and good abstraction for the engine.

Dynamic nature

Pros & cons of dynamic typing

GDScript is a Dynamically Typed language. As such, its main advantages are that:

  • The language is easy to get started with.
  • Most code can be written and changed quickly and without hassle.
  • Less code written means less errors & mistakes to fix.
  • The code is easy to read (little clutter).
  • No compilation is required to test.
  • Runtime is tiny.
  • It has duck-typing and polymorphism by nature.

While the main disadvantages are:

  • Less performance than statically typed languages.
  • More difficult to refactor (symbols can't be traced).
  • Some errors that would typically be detected at compile time in statically typed languages only appear while running the code (because expression parsing is more > strict).
  • Less flexibility for code-completion (some variable types are only known at run-time).

Additionally, the interesting thing for me, it resembles Python

It uses an indentation-based syntax similar to languages like Python. GDScript is entirely independent from Python and is not based on it.

and because I come from Rust, this is mind-boggling for me:

Memory management

Godot implements reference counting to free certain instances that are no longer used, instead of a garbage collector, or requiring purely manual management. Any instance of the RefCounted class (or any class that inherits it, such as Resource) will be freed automatically when no longer in use. For an instance of any class that is not a RefCounted (such as Node or the base Object type), it will remain in memory until it is deleted with free() (or queue_free() for Nodes).

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 6 months ago (2 children)

I'm afraid I don't have a specific example in GDScript, but I have written enterprise software where this was the case.

When talking about the speed of languages we often focus on the runtime speed. But another important factor is development speed. In my experience, an interpreted language such as GDScript or Python has a much faster development speed than a compiled language. This is really great for prototyping, especially when you don't know exactly what changes you might have to make on the fly.

The philosophy that I have is to avoid premature optimization. And what I mean by this is that I'm going to write the program the simplest way I can think of the first time. Of course, the first draft isn't always the best solution, and if there are issues they'll make themselves apparent. Once they make themselves known, then we can address resolving them.

So now that you've identified an issue you can work on optimizing it. You'll want to do some profiling to find the problem areas, but generally the issues will make themselves known. Some portion of the program will need a rewrite and you can begin working on that. There might be bad control flow or an unhandled error, and those are easily fixed. But sometimes it boils down to a computationally expensive algorithm.

If you encounter a problematic algorithm, you might have to write it several different ways to figure out what's fastest. After all, most problems can be solved in many different ways. But eventually, you're going to find your fastest solution. And if that solution still isn't fast enough, then it could be time to look at switching to a compiled language.

I guess what I'm getting at is that out of all the tools in the toolbox, rewriting to another language is the last one I reach for. However, it is still sometimes the correct solution.

Thank you for reading this far. As for some Godot stuff, they have this cross-language scripting feature. Basically, you can fairly easily interface some C# into your GDScript when and where you need it, instead of deciding on one specific language at the start of your project.

[–] BirbSeed 7 points 6 months ago (1 children)

This is the way. One additional step I do for enterprise software is test driven development. That way when you refactor your code into something better, you still have tests in place to verify that the code actually works.

[–] [email protected] 4 points 6 months ago

This industry needs tests so damn bad