Godot 4.x is significantly slower than 3.5.1 in creating nodes

[Overvault-64]

Godot version

4.0.beta10

System information

Windows 10 and Android

Issue description

In my projects I often need to create UI at runtime, instantiating a lot of elements.
This brought to my attention a relevant performance issue in Godot 4: when creating nodes, or instantiating them, it's about 4 times slower than Godot 3.

I've repeated the tests several times with my test projects making both versions instantiate a scene (a button containing 3 child nodes) different amount of times, from 1000 to 8000, and the result goes from more than 4 times to almost 4 times slower.

Godot 4 crashed when instantiating more than 8000 of those scenes, while Godot 3 handled more than 10000 comfortably.
My hardware was below 30% workload all the time.

I've also tried creating the button at runtime and it makes no significant difference compared to instantiating a pre-made scene.

This wouldn't be a real-world problem for most developers (except me, I guess) if it wasn't way amplified on mobile.
My mobile test device required 6-7 times more time to complete the task on both versions, leading to an unhealthy 21 seconds with 8000 scenes on the Godot 4 build. The Godot 4/Godot 3 lag ratio on mobile is quite the same as on pc.

Minimal projects attached

Steps to reproduce

Start the projects

Minimal reproduction project

node.test.zip

[Calinou]

Related to #61929.

Are you using an official engine build in both 3.x and 4.0.beta (i.e. with the same optimizations)?

[wardPlaced]

Doesnt that mean that the engine is capable to handle more nodes with less of a ressource uptake or spike thereof? Isnt it possible to adjust these things in the profiler? I think Godot has one already. So that needs more thorough observation and testing. Plus, running them alongside is not indicative. Some CPUs are capable of repeating workloads when they understood them I heard... they dont seem to be in circulation. Can people change that. Sorry for being so unfactual. Yes, optimization does not matter if you can adjust the thread size, but that could limit mobile phone performance, I mean Android specificaly, because you are locking yourself out of certain devices that dont have the RAM to deal with the work load, even with blast processing and spiked CPUs, which they all are in the Mobile hemisphere, so clocktimes must be an issue for the new release, and if so, why are they not? If its all software anyways and we are reading from self updating text files then thats Linux fixing that. I feel like this is way more interessting if you think closer than with an open eye, BUT heres the deal... it just takes longer because people want to have more nodes in their projects created by hand or while running, right? so that takes more power on average to handle because thats how streams and data work, once you turn it into something closer to a machine, you can rearrange it and it will still present the same way to the user with less data taken up in all regards. Sounds crazy its the truth, not advised for smaller data sizes, like a thousands buttons... but you have a keen eye... good job! im not an expert! but that seems to be the general thing when it comes to handeling LOTS of things at THE SAME time. everything else is just an illusion of that and its handled one by one, which doesnt create the necessary behavior anyway.

[Overvault-64]

Related to #61929.

Are you using an official engine build in both 3.x and 4.0.beta (i.e. with the same optimizations)?

Yes

[Overvault-64]

Still slow in beta13

[Overvault-64]

4.0.1 (stable)

[Calinou]

Can you reproduce this with a self-compiled editor build with the production=yes module_text_server_advanced_enabled=no module_text_server_fb_enabled=yes SCons options? This uses a simpler and faster TextServer that has advanced features disabled (no right-to-left or complex scripts).

[Riteo]

@Calinou good point. While the issue title describes "nodes" in general, this benchmark uses UI nodes, which aren't exactly simple.

[Overvault-64]

@Calinou I don't have a compile environment set up, but @Riteo 's comment made me think that I can benchmark different kind of nodes and look at the results. This way I could see which node types are harder on the engine and maybe identify a common cause. Makes sense?

[Calinou]

but @Riteo 's comment made me think that I can benchmark different kind of nodes and look at the results. This way I could see which node types are harder on the engine and maybe identify a common cause. Makes sense?

You can try to do that, but the best way to isolate the bottleneck is to switch TextServers as I mentioned. I get a strong feeling the slowness is due to text shaping, not node creation. Text shaping in 4.0 regularly comes up as one of the most demanding operations when I look at results in a C++ profiler (the editor profiler won't show it).

You can also use a C++ profiler on a debug build of the engine.

[Overvault-64]

@Calinou I hope I did it right
Here are the results but I don't know how to read them

I've used the godot-4.0-editor-debug-windows-msvc2022 build