Godot Static Typing - Is It REALLY Faster?
HTML-код
- Опубликовано: 31 июл 2024
- Curious if static typing can boost your Godot game's performance? Discover the answer in this video where we dive into the numbers and show you the results!
👉 Official Godot 4 Static Typing Documentation:
docs.godotengine.org/en/stabl...
0:00 Intro
0:30 Defining variables
1:57 Benchmark results
3:05 Conclusion
#gamedev #godot #gamedevelopment
for me, the performance benefit is not really what I care but using static hints it's much easier to find/prevent runtime errors and you get autocomplete which are awesome things
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.
Once you get into static typing, you never go back
lol it’s good to have good habits I suppose ;) thanks for watching!
Something you didn't mention in your video, but i think is equally just as important, is the developer experience when working with statically typed variables. Using statically typed variables allows Godots autocomple to work WAAAAY better, helping the developer write better, less buggy code.
For example, if you create your own class with its own functions and properties, the autocomplete will not show you those things sometimes unless you use static typing (in combination with type casting sometimes)
Great point! Autocomplete is so nice when it works! Thanks for watching!
Static type in general programming is very recommended. It helps the compiler a lot when generating and optimizing the machine code (assembly) and resulting generally better execution as well.
Yeah it’s an easy way to add some optimizations. The effort vs reward definitely seems worth it. Thanks for watching!
That's it, *statically types your dynamic programming language*
In my opinion, the performance of static vs. dynamic typing does not matter, even in the high-performance context of a game. 99.9% of the time, the performance bottleneck comes from an inefficient implementation, never the language itself being slow. The biggest benefit of static typing in my eyes is the ability to implicitly assert the type of a variable and ensure that it will not change. It makes bugs in the form of accidental redefinition and misspelled variables more likely to be caught earlier in the call stack, it helps make common programming idioms easier to notice, as you do not ever have to worry about the type of a given variable changing, and you won't ever have to do explicit type assertion in your functions.
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!
for me, I just love how static type is waaay more readable, look at this
func test(a, b):
return a + b
now using types:
func test(a:float, b:float)->float:
return a+b
Yeah it definitely makes it easier to see what’s going on! Thanks for watching!
Hey guys, if you keep forgetting to static type your variables (or just want godot to yell at you), there's a project setting in the Debug > GDScript > Untyped Declaration option to change into Error. Hope this helps~
p.s:
funcs also need to be type declared like, func example() -> void:
i'm fascinated by this, given that i've never seen anyone ever actually run stats for static typing's effect on compilation/performance. for the benefit of the audience, what i would love to have seen would have been a brief explanation of why there is a performance increase.
the increase arises from the fact that the compiler has to 'figure out' the type of every variable used in a codebase, and then allocate the corresponding type/memory, before then performing any calculations using those variables. and then those calculations need to be validated against its initial guesses, before it goes back and corrects them as needed. this is a lot of complex, time-consuming work that happens mainly during initial parsing/compilation, but also partially at runtime. by clearly indicating to the compiler what your intent is, and then reliably sticking with that intent, it removes this unnecessary work, and thus dramatically reduces processing time.
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.
Performance improvements are a nice plus, but the real advantage of types is documentation. Especially when working in a team, using a dynamically typed language is a recipe for disaster in the long run.
The type checker goes not away by using a dynamically typed language. The type checker is now you. So you will have cognitive overhead and have to reverse engineer the code base when you don't have types and come back to your project 6 months later.
The best example would be add_address(user) vs add_address(user: User): User.
With the second function, you will see on the first glance that the function will take a User and return a User. You can jump to the definition with your editor/IDE of choice, to see what a User actually is.
With the first function, you will have to read the code and usages to get a clue what's going on.
So besides cognitive overhead you have to have good documentation, which has to be revisited on refactoring and to be honest, documentation will diverge with the code, when time passes.
great points! documentation can be such a slog! i also really enjoy well-commented code when working with a team.
Bonus: it's just more convenient for self-documentation, and Godot can autocomplete functions for you if you tell explicitly which class/type is put into a variable.
I also like to use it as it allows for better type hinting in the ide and if I forget the type of a var and do something silly, it throws an error.
Yeah better autocomplete is always nice! Thanks for watching!
For someone who originally learned programming from languages such as C# and Java - Static typing just feels more right for me!
go with what you know! thanks for watching!
Not to mention the warm fuzzy feeling of compile time safety 🥰
One question I have in my mind: With := Godot still has to do type inference (guessing the type, as you called it). Would declaring the type (var health: float = 50.0) be even more efficient?
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.
Hey swydev, I was on a business trip and couldn't verify the impact instantly, that's the reason I didn't reply yet. Was going tonreply and saw this video, hehe😅
No need to blur the name, but thanks that you did without showing clear name without asking!
I also wanted to mention that the line counters indicate if all values are statically known for godot or not. Green line indicator means better performance than grey. This indicator was introduced witj 4.x i think.
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 👌
Static typing is not really for the speed, but to help write organized code and to pinpoint bugs faster. Like someone said, once you use it and understand why, you never go back.
I feel like this video is missing the entire point of statically typed languages. It's mainly about type safety, and makes it a lot easier to keep track of what functions and operations you should be allowed to perform with your variables. I find this especially useful when variables can be transferred across different scripts, like in functions and signals. Also makes writing code easier with autocomplete suggestions.
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.
Dang, you got a new subscriber
Let’s go! Thanks for watching!
Wow, that was really interesting, I thought the impact in performance would ve minimal.
Thanks for this video! ❤
Yeah I was surprised as well! We're really only talking about milliseconds here, but it all adds up! Thanks for watching!
The walrus operator!
lol i love it! ;)
Sick 2j though
Better way for a lot of reasons is to specify the type. Eg:
var health: int
var velocity: Vector2
func get_health() -> int:
return health
func get_velocity() -> Vector2:
return velocity
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 😁
To note here, you could have static typed your for loop as well
for i: int in range(LOOPS)
Not sure how much this would have affected the outcome, but something to point out
You can also tell your function what to expect to be returned with -> type before the colon when declaring a function. For example
func _process(delta: float) -> void:
void means to expect nothing to be returned but you can easily replace this with another data type for example
-> float
-> int
-> Vector2
and so on. Just two more things to share
Great point! Thanks for sharing! Now I’m curious what kind of impact that would have lol
I just can't look at "var dookie=1",
I love typing "var dookie: int = 1
🤣
Another consideration is if your end user is on mobile on anything with a battery such as a laptop. The less work the computer is doing, the better the battery life.
great point! i can't stand it when one app eats up all my battery! :) thanks for watching!
Im finally sold. My small game just happens to run 1m computations (3D procedural dungeon). And yeah it's slow. But now it can be 20% faster than slow!
Nice! Lol every little bit helps when you have a lot going on
Very interesting thanks.
Thanks for watching!
Faster or not, static typing is the way to go. This helps you prevent bugs and unknown errors later down the line. Take your example of an int becoming a float later in the code; sure, it could be handy in a certain situation, but in that case, change the underlying type. Imagine you're creating a grid system, and use ints for the position. It would be strange if you suddenly got a bug where the grid position is 6.423 no? That is the strength of static typing, as it makes that impossible.
(Not hating on the video, just a little comment :D)
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!
Hi as a complete beginner to programming, how does one learn static typing from the get go? Is it the same as oop? Should I start with gdscript or python? Or something else. I don't have a galaxy brain 😁
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.
There's almost no reason to ever use dynamically typed variables. There's never a good reason to change the type of a variable after it's defined.
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é ;)
Static typing isn't used for performance, it's used to catch errors at compile time instead of runtime.
I mandate for my team, the only time := is used is if the type is named immediately after. Eg var v:= Vector3(0,0,0). Otherwise we always use the full format for code readability. Eg var v: float = 1.0.
You won't see a significant performance boost unless your code is bound by GDScript, which it should not be if you're programming optimally. Your GDScript should be mostly event driven, pushing the work onto the engine. If your game is GDScript bound, static typing is only a bandaid for poor design. Greater improvements will come from restructuring your code.
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.
There's no actual static typing in GDScript, just type locking. Any piece of data is technically a Variant.
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.
Accurate benchmarking and profiling is more complex than the very simplistic code you showed. For example, for most scripting languages you'll want to exclude outliers caused by garbage collection. Not to mention that micro-benchmarks like yours that show 20% improvement may well have negligible impact on more realistic code. That said, static typing all the way for me, I would not go back to dynamic typing for anything more than 10 lines of code.
Thanks for watching and sharing your thoughts!
Can you make tutorial about shop system
Got it on the list! Thanks for watching!
wow, thats cool, but sometimes you want to keep dynamic type, for instance - collider of raycast3d
Yeah it’s nice to have the flexibility for sure. Thanks for watching!
WOW actual stats!
But, now my brain wonders about strings, and functions and function returns.... And if Godot does the Java trick I've heard about called inline functions? (As in the performance drop for splitting your functions toooo much) 😅 Yea it doesn't matter for most code. Cool preso!
Yeah all the little stuff adds up! Thanks for watching!
if it’s that simple, it begs the question: why doesn’t the language always put the colon in by default, aka, under the hood, = just always equals := ?
There must be a reason it’s seperate, other than just something benign like “it only works with simple types”
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.
Godot Mono Still Faster btw
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
Disliked cause of AI thumbnail lol.
ok. Thanks for watching!