What do 3.1 docs mean by "scripts will operate a little slower than scenes"?

system · February 25, 2019, 5:23pm


	Attention	Topic was automatically imported from the old Question2Answer platform.
	Asked By	Charlie

This statement is in the new 3.1 docs section “Best Practices,” subsection “When to use scenes versus scripts”. I’m a bit puzzled about this whole section, which may result from some basic misunderstandings.

I have a large project where essentially all of my spatial nodes are generated procedurally via GDScript. In the past, I would have a pair of *.tscn and *.gd files for each node, and then I would instance a spatial node by the instance() call on the preloaded *.tscn file. In my understanding, this is a “scene”. However, I never edit any of these scenes in the editor – only their scripts. I figured out later that I can reduce project clutter by having only the *.gd file, deleting the *.tscn file entirely, and instancing by the new() call on the preloaded *.gd file. In my understanding, this is a “script”.

The latter approach is less cognitively demanding with the specific advantage (for my project**!**) that I cannot inadvertently alter a node property outside of GDScript. However, the docs make me think now that the former approach has some kind of engine/C+±binding/implementation difference that might provide some small runtime advantage. Is this correct?

system · February 25, 2019, 6:28pm


	Reply From:	Zylann

If you do everything by code, that means you are taking away the whole scene tree editor, inheritance and instancing system from eventual non-coders working with you. In that sense, it makes the workflow more difficult, unless you are on your own, have only coders or other means of tweaking scenes.

Doing by script or by scenes is not wrong per se, it’s two different ways of going (built-in C++ nodes litterally are procedurally build in that sense, take a look at what ColorPicker actually is in a running game). It’s just that due to the above, using scene files is more common for teams and enable useful features of the scene system which would be tedious to make by code.

Performance side, I don’t think there is too much difference between instancing a scene file or building it by script (at least just a raw one without overrides or anything), but doing by script will at least have a penalty because of the cost of running that script in the first place. When Godot instances a scene, it has all information ready to be set on new node instances, while a script is interpreted bytecode and needs to do everything manually. If you are concerned about performance you could compare how long it takes for a scene to be instanced compared to its script equivalent.

I should have been more exact in my question. Is there any difference in runtime performance after the nodes are added if I add nodes in the above two outlined ways? I think the exact wording “will operate a little slower” lead me to think there would be performance hit even after the nodes are created and added to the tree.

The precise situation is that I’m building a solar system simulator with realistic orbits of planets, moons, & very many asteroids & comets. It’s much easier to read data from formatted text files (and grab images from directories) rather than build 1000s of objects “manually” in the editor. Yes, my use of “manual” here is the exact opposite of yours. In my project it is easier and less error prone to add a row to a table (and an image to a directory) than to mess around in the editor.

Charlie | 2019-02-25 19:07

Oh yeah I was only talking about the instancing part, because that’s the part you seem to be changing for another approach. The way nodes are instanced doesn’t make a difference in how they perform afterwards, since the result would be the same.

One of the point is, the more things you do from script, the slower these specific things will be compared to using engine functionality, which is C++.

Zylann | 2019-02-25 19:35

OK, thanks! This clarifies that my worry was a misunderstanding. Yes, building a node by GDScript takes time, but the resulting node isn’t at any disadvantage thereafter. This is exactly what I wanted to hear.

Charlie | 2019-02-25 19:52