Comments on C# code and questions

[Ignacio Roldán Etcheverry]

Hi, thanks for the benchmark. It's hard to tell without profiling but I think the C# code would benefit a lot in this case if Godot use object pools for the instances it creates internally. There is also room for improvement on methods that return nodes such as (Label)GetNode("") which do not have a C# script attached.

Here is a tip about NodePath:

Passing a string to GetNode everytime it's called is slower than in GDScript. The reason is that GDScript detects this at compile time and optimizes it to only create the NodePath once and re-use it. The equivalent in C# would be:

NodePath fpsLabelPath = "../gui/list/fps";

public override void _Process(float delta) {
    GetNode(fpsLabelPath);
}

This probably applies to GDNative as well, not sure.

Some questions:

• What configuration is the project compiled with, Tools, Debug or Release? The Tools config is the same as Debug plus some editor specific options. You can change that by building with msbuild /p:Configuration=Tools;DebugSymbols=false;Optimize=true.
• Where are the sources for the get_children test?
• I wonder what the results would be if var bunny = new Sprite(); used an object pool instead. Maybe we could have an extra test with pooling.

[Carter Anderson]

Thanks for the comments @neikeq! Yeah I'm guessing pooling will help. And in most cases if you have knowledge of the less performant calls they're relatively easy to code around.

The project was compiled with Tools (my bad). I will use the command you listed above in the next run.

I've been reworking the benchmarks and a part of that included removing the GetNode calls. I will probably add some other benchmarks that make use of GetChildren, GetNode, etc. And when that happens I'll definitely take your NodePath caching suggestion into account.

[Carter Anderson]

Just realized I forgot to answer "Where are the sources for the get_children test?". Sorry I wasn't trying to deflect your question. The get_children tests were identical to the original tests, but I added var x = GetChildren(); once (for the first test) and five times for the others.

Pretty crude, I was just trying to make a point 😄

[Ignacio Roldán Etcheverry]

Actually, building the assemblies with optimizations enabled is not enough. Godot enables some debug settings at startup on debug/release_debug builds. The right way to do it would be:

• Build a Godot release template with mono enabled: target=release tools=no module_mono_enabled=true. Debug settings aren't enabled on release builds.
• Build the project assembly with /p:Configuration=Release.
• Run the project with the release export template. godot --path <path-to-project> (or just place the executable in the project folder and execute it). It will look for the project assembly in the right directory (res://.mono/temp/bin/Release/).