Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time.

Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them.

In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

> Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. ... In case you use C++ you will be able to use mature profilers

Why couldn't you use your regular mature C# profiler like you do anywhere else? It's officially supported. Both the mono profiler and JetBrains work.

> In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

You can do exactly that right now. Use the C++ profiler to find hotspots in Godot and the C# profiler to find hotspots in your code.

I can easily answer both of your questions. Because I obviously want to know how much time exactly game code takes together: both engine and "scripting". Using weird combinations of two different profilers is not a good day to work on code. Both Unreal and Unity have proper usable profilers and Godot doesnt.

Also unfortunately our project is usingGDScript and there is no profiler for it.