GDScript vs C# performance

[dragmz]

Godot export templates:
https://downloads.tuxfamily.org/godotengine/3.2/mono/Godot_v3.2-stable_mono_export_templates.tpz

Projects:

• GDScript (gdlife) - https://github.com/dragmz/gdlife/tree/759ce2053569e5ebcc8e80ffa9087be005090979
• C# (gdlifenet) - https://github.com/dragmz/gdlifenet/tree/d3d379a32d237a0553c040ca518f7a361e5d9621

GDScript takes 10x longer than C# to execute. Results for rendering the first 1000 frames are (in milliseconds):

Intel Core i5 650 @ 3210 MHz, GTX 950

#	GDScript (gdlife)	C# (gdlifenet)
1	17090	1743
2	17216	1711
3	17575	1700

How to benchmark:

1. Clone the projects repositories
2. Create exported builds of the projects
3. Run the exported builds and wait for the run to complete - the result is printed to stdout

--

The purpose of this issue is to keep a track on the performance in case there are any optimizations implemented in the future.

[nathanfranke]

I am kind of curious why GDScript would be that much slower. Isn't it converted into bytecode?

[Calinou]

@nathanfranke I don't remember if bytecode compilation is still present. If it is, keep in mind it only speeds up how fast the script loads, not how fast it runs (just like in Python).

[Zylann]

I've been doing GDScript microbenchmarks for a while: https://github.com/Zylann/gdscript_performance

@nathanfranke C# uses JIT to convert its bytecode into CPU instructions and is able to use ptrcalls (calling engine functions directly). It also had years of optimizations and features that allow to use CPU power and memory more efficiently (structs, string interning, GC...).
GDScript on the other hand uses a giant switch/case for its instructions, checks types of everything at runtime before operating, accesses functions using maps, uses Variant for everything and does not use ptrcalls. So right now it makes sense that it's much slower. It could be theoretically better due to its tight integration, the rest outweights those benefits.

[Shatur]

Bad to hear. I really like GDScript.

[jabcross]

As I understand, GDScript is not intended for use in CPU-bound situations, it's just a convenient language for beginners that's tightly coupled with the engine specifics. Most games' CPU-bound use-cases are intended to be covered by specific nodes.

For CPU-bound situations you can use C#, GDNative or write a module.

[ShlomiRex]

As I understand, GDScript is not intended for use in CPU-bound situations, it's just a convenient language for beginners that's tightly coupled with the engine specifics. Most games' CPU-bound use-cases are intended to be covered by specific nodes.

For CPU-bound situations you can use C#, GDNative or write a module.

Agreed, though it is interesting topic.
I wonder if Native script (C++) is much faster than C#?

[dragmz]

I wonder if Native script (C++) is much faster than C#?

I've got a Godot module implementation of the algorithm available here: https://github.com/dragmz/gdlifemod (tested with MSVC 2019 only)

[jabcross]

I wonder if Native script (C++) is much faster than C#?

C++ is theoretically as fast as it can possibly be. Unless you want to write assembly :D

Seriously though, C# is pretty fast as long as you're not memory-bound. Otherwise you get the same problem as Java: lag spikes on garbage collection.

[aaronfranke]

Unless you want to write assembly :D

A bit off topic, but... due to the sheer level of sophistication of compilers, it is extremely likely that C++ will outperform handwritten assembly. For trivial cases, the compiler has those cases optimized. For non-trivial cases, the problems are likely too complex for a human to hand-optimize the assembly.

Back on topic, here are some more benchmarks: http://www.royaldonut.games/2019/03/29/cpu-voxel-benchmarks-of-most-popular-languages-in-godot/ Note that voxel generation is a use case which can be given many low-level optimizations, so C# and especially C++ benefit a lot here.

[girng]

Bad to hear. I really like GDScript.

Please don't let specific benchmarks like this change your decision on GDScript :)

GDScript is not just for beginners, and it's certainly not slow (relative to a smooth gaming experience). There are trade-offs with any language. The sheer power and rapid prototyping GDScript offers, while giving the developer the chance to build their dream game, should not be overseen.

[Shatur]

Please don't let specific benchmarks like this change your decision on GDScript :)

Yes, I'm will use it :) I think that if necessary, I will rewrite the bottlenecks in C++.
The documentation also says that static typing in GDScript may increase performance in future.

[bojidar-bg]

Note that GDScript uses real Godot Objects and the ObjectDB for managing them when creating sub-classes in a script. Also it will create ScriptInstances for each of them, and make every variable access on such a script go through a few levels of indirection (thankfully, it will not do string comparisons, but hashmap and red-black tree lookups are enough).
C# on the other hand, can get away with not boxing int-s and bool-s as Variant-s, not storing any excess information in the private classes, apart from what the garbage collector needs, and not doing any hashmap or tree lookups when reading variables from them. Also, it can place objects next to each other in memory, improving cache locality.
Thus, I suspect a lot of the slowdown in this benchmark comes from the fact that the GDScript version does a lot more computation than the C# version. Some of the difference may be eliminated by using a PoolByteArray or two to store the values of the tiles, instead of creating actual tile objects.