Godot Static Typing - Is It REALLY Faster? 

yeah its nice to have the engine push you in the right direction for sure. the performance benefits definitely don't hurt though! it's really great that you can get both at the same time!

100%, I use type hints everywhere.

Great point! Autocomplete is so nice when it works! Thanks for watching!

lol it’s good to have good habits I suppose ;) thanks for watching!

Yeah it’s an easy way to add some optimizations. The effort vs reward definitely seems worth it. Thanks for watching!

Great points! Benefits are benefits - cutting dev time down by having more clear code can boost a project in so many ways! Thanks for watching!

Yeah it definitely makes it easier to see what’s going on! Thanks for watching!

great points! it makes total sense that requiring less of the compiler would lead to increased performance. i was surprised to see that using := vs explicitly defining the datatype like var myVar : float = 0.1 didn't seem to make a difference even though it would force the compiler to guess the type when the variable was first defined, but i guess it would be negligible compared to actually overwriting the variable or running calculations multiple times

@@swydev aye honestly it surprises me, too. between persistent suspicion over this, the clarity provided by explicit typing (var foo: String), and following years of working on shared codebases in professional teams, i never use := and instead just type everything out (var foo: String). it's a pain, but benefits you in the long run, and becomes more or less reflexive after a while.

great points! documentation can be such a slog! i also really enjoy well-commented code when working with a team.

I played with that and didn’t see a difference. There may be one but since the variable is only defined once it seems insignificant.

Not a Godot internals expert, but at a guess: While a type does have to be inferred when using := , that inference happens once when the script is compiled. After that, the type remains static and doesn’t have to be inferred every time you run the code. So the performance cost is paid before your game is even running.

Yeah better autocomplete is always nice! Thanks for watching!

go with what you know! thanks for watching!

Nice! Yeah no worries I figured I was curious so I’d go ahead and test it out! Appreciate you pointing it out!

​@@swydev is definitely great, having real numbers to back it up now 👌

Yeah I was surprised as well! We're really only talking about milliseconds here, but it all adds up! Thanks for watching!

It definitely makes code easier to read and maintain. I was curious mostly of what performance impacts there would be when using static typing vs not. As it turns out, while being helpful during development, static types can also positively impact end user experience in a way that better variable names or proper commenting habits can’t.

lol i love it! ;)

Let’s go! Thanks for watching!

🤣

yeah i didn't cover typing functions here, but I'm curious what the advantages are to using var health : int = 100 vs var health := 100. In my tests, they were the same performance-wise - what other benefits are there to explicitly typing them like that vs using the := shorthand in your experience?

@@swydev There is none from the pure functional standpoint. The only difference is that it's more readable, expressive and consistent. If for instance you have something like: var stuff := some_function(param1, param2) You have no clue which type the function returns unless you look it up which can become quite tedious over time. And for function parameter definition there is actually no way around that to specify them with name : type syntax. So in order to have better readable and consistent code it'd be better to just stick with one syntax to express static types. At least in my opinion this makes it easier to read and understand.

@@AlexanderKoch84 great points! Having readable code can have so many benefits even working solo. I appreciate you sharing your knowledge. I’d imagine that there could be an argument made that having more readable code encourages more you to write performant code inherently also - so a double benefit to using static typing given the technical performance enhancements paired with better code overall.

@@swydev That's the beauty of static typing in a (by default) dynamically typed language. It's not just more readable but also faster. Usually performance optimizations - especially the tricky ones - come with the drawback of more complex and harder to understand code but in this case it's combining better readability with faster execution - win-win 😁

Great point! Thanks for sharing! Now I’m curious what kind of impact that would have lol

Thanks for watching!

great point! i can't stand it when one app eats up all my battery! :) thanks for watching!

Nice! Lol every little bit helps when you have a lot going on

Great points! Static typing can definitely be the equivalent of using bumpers at the bowling alley. It will force your code to adhere to the rules. In almost all cases this is a good thing. Do you have to use it to avoid bugs? Certainly not, but it doesn’t hurt. Looking at performance was interesting to me because it’s directly related to the end user experience by allowing your game to run better on more devices regardless of dev habits, experience, team size, etc. Thanks for watching and sharing your thoughts!

what are your thoughts on using dynamically typed methods for polymorphism?

@swydev not really sure I know what you mean. An example might help. But in general I'm against changing the meaning of a variable/ method after definition. So if you mean you'd like to swap in functions with a completely different set of parameters or return type, I'd definitely advise against that, mostly in the interest of programmer sanity:)

An example would be if you had a method to perform some sort of math, for example it might add two numbers together and you wanted it to work for floats or integers. By statically typing the method, you could only ever return one or the other (float or integer) and would need 2 functions for the same task. A dynamically typed method could use the same code regardless of what data type was passed in and return a value in the same data type supplied

@swydev fair enough I seewhat you mean. In that case I'd prefer to use a common super type, i.e. number, if available. If that didn't exist then the options are either have overloaded versions, which would require every possible combination of types you want to support, or untyped parameters, which are probably your best option. Touché ;)

How do you distinguish between static typing and type locking?

Static typing is about normal data allocation where you allocate a 32-bit integer - you get a 32-bit integer. Dynamic typing or duck typing is about using one universal compound data type (e.g. Any in Python) that switches between modes. This data type has one fixed size of at least 64 bits. For example, you cannot allocate 8192 bytes of total size of 65536 bits, you can only allocate 8192 wildcards that will act as bytes and will occupy at least 8 times as much memory. GDScript communicates with the engine through bindings. When you call a bound low-level function, you pass the wildcard type data as the arguments and receive the returning data as that type too, which creates certain overhead. Type locking is simply the wildcard data type mode switch restriction.

@@swydev Static typing -- type doesn't change and underlying data format is the type. type locking -- type doesn't change and underlying data format is some universal wrapper that has different modes representing the different types. I tried to sum up Rex's answer a bit more but he's got it aside from the part about not being able to allocate exact amounts of memory. It'll end up being slightly larger for the Variant overhead, but because there's built-in packed array types, it's not going to occupy 8x the memory to get 8192 bytes in a contiguous array. It would if they were all separate objects; maybe that's what he was referring to.

Start with the basics and work your way up to understanding the concepts when you need it. Try to apply what you learned and always critically raise the question for yourself: "There must be a easier/better way to do this". With that you'll get better and more knowledgeable over time. Don't stress yourself out that there are a lot of concepts, languages out there you don't know yet and don't try to get everything at once with falling into the tutorial hell. Just start small, apply what you already know and learn new stuff on the side to improve. I presume you're interested in gamedev and godot by clicking on this vid so that'd be a good starting point. There are a lot of "how to start a simple xy in godot" videos out there - pick one up which is of interest to you, follow it through and don't just copy+paste everything but rather try to understand what it actually does - that would already be a good foundation to work with and later when you have the basics you can dip into more complex topics like dyanmic vs. static typing, oop and other concepts. Hope that helps and good luck on your journey ;-)

This is fantastic ;)

To add to Alexander’s reply, I agree godot is a great starting point. Working in a game engine can help you understand what the code does more readily than learning a language solely to learn the language. I find it easier to learn something new by building an actual project vs doing scripting exercises.

I am in the same scenario too, I always watch these videos to know how "advanced" programming works but never really understand them since I'm a beginner. The basic thought process is that when you encounter a problem or better implementation in your coding journey, informational videos will be the go-to. The problem is that you don't know *when* this kind of coding advice will become useful in your own code. So, information like this is kinda useless without probably intermediate coding knowledge or extensive previous experience. So I always just watch these videos for possible future reference.

@@sebastercats6123 Experience is your guide. If you don't know why a concept would be useful from a brief explanation, you probably don't need to know it yet (some things are more fundamental and are worth learning as soon as you can, but may not be necessary to make stuff work), write more code, figure out the differences between the various ways of doing things that you do know. Experiment and have fun whenever you can with simple projects.

Great points! Thanks for sharing! So are you using C# for most things then? What’s the advantage of mixing languages vs abandoning gdscript for a faster language all together?

@@swydev We use GDScript for Out of the Ashes. 18k lines of code sans addons, blanks, shaders, and comments. And C++ for Terrain3D. There's no need for C# since we've pushed the work onto the engine. I'd only recommend it if it's the language of choice. Our performance is limited by the renderer, and VRAM, not GDScript.

@TokisanGames very cool. I’ll admit after using Unity, good terrain tools has been something I’ve missed in godot. If you have a dev log or write up on how you’ve handled it I’d be really interested to check it out!

@@swydev I'm not sure what you mean unless you haven't heard of Terrain3D. This is a C++ Godot addon we released a year ago. I've produced 3 videos on how it works on my channel. Some say it's better than Unity tools, but I haven't used them so can't compare.

@@TokisanGames ah yeah i've heard of it! didn't realize you were the team behind it! that's awesome! I thought you were referring to using C++ for procedural terrain generation or something to that effect.

Got it on the list! Thanks for watching!

Yeah it’s nice to have the flexibility for sure. Thanks for watching!

Yeah all the little stuff adds up! Thanks for watching!

Thanks for watching and sharing your thoughts!

Great question! Wondered that too. I’m not sure I know the answer though lol possibly because it’s built as a wrapper to another language like C++ or maybe a design decision in case a dev has a valid use case where they would change the type later in their code?

I did a little reading and discovered you can actually force strict typing in the editor under Project Settings -> Debug -> GDScript -> Unassigned Variable if you have Advanced Settings enabled. Doesn't make it happen by default, but you can set it to warn you or throw an error if you need a push to remember to use it.

Sometimes, you want to keep things in a dynamic type because some later code might attempt to change the value to a different type. If the type was static, things would break at that point. Most dynamic languages (e.g. Python) take the approach that allowing this is better than crashing.

Having enforced static types would break legacy code and code examples/tutorials. The whole idea behind dynamic types is that you can change the type later. As a simple example you start our with a variable "health=10" but later you want to substract 0.1 for hits. With enforced static types this would be a mess (most likely having an implicit float cast for the operation and when assigning cutoff which results in 9 instead of 9.9). Adding these kind of features and optimizations at a later stage (static typing) always comes with the caveat that you need to stay compatible with existing code which brings us to the explicit way to declare it to make it clear and expressive. And as others have already pointed out you can set this up in the editor to warn you about non-static types in the code, which I'm personally also using to keep things tidy and fast.

Do you know if mono is faster using GDScript? or only if you're using C#?

Godot C++ still 10x faster than C# btw

@@TokisanGames the hardest way 😅

@@swydev especially for standalone algorithms

ok. Thanks for watching!