Buildsystem performance: Clean build and null build reports #42048
Comments
|
Config:
Clean buildNull buildNote: The first null build after the clean build took longer as it seemed to relink Then subsequent null builds don't relink Leaf buildAfter clean/null builds, modified |
|
It would also be interesting to see how fast builds are with the generated ninja files once that's merged. |
|
Computer Info: Compiler: Scons: Builds: Clean Build: Null Builds: Null Builds Data1: 2: 3: 4: 5: Leaf Builds: Leaf Builds Data1: 2: 3: 4: 5: |
Config
Clean buildNull buildsfirst run (@akien-mga ):
same here second run: third run fourth run Leaf buildsfirst run: second run: third run: I'll provide timings for my laptop in a separate comment. |
|
Second test on my system drive, which is a M.2 SSD Compiler: Scons: Builds: Clean Build: Null Builds: Null Builds Data1: 2: 3: 4: 5: Leaf Builds: Leaf Builds Data1: 2: 3: 4: 5: |
Configuration
Clean buildFirst null build (relinks libcore)Second, third and fourth null builds (doesn't relink anything)Leaf builds (modifying a description in
|
|
Third test on my hdd. Compiler: Scons: Builds: Clean Build: Null Builds: Null Builds Data1: 2: 3: 4: 5: Leaf Builds: Leaf Builds Data1: 2: 3: 4: 5: |
|
Config
Clean BuildNull buildNull build 2, 3, 4Leaf buildNote: This was all significantly worse with Scons 3.1.1. Null builds were 20+s and subsequent null builds did not improve in speed. |
Config$ inxi -DCmSP
Clean buildNull buildFirst time with relink libcore: After that (x3): Leaf build
|
Config
Clean buildFirst null buildNull builds 2, 3, 4Leaf build |
Config:Building with Godot: clang: Clean build:Null build 1:Null build 2 (similar times for subsequent runs):Leaf build:If it's still relevant (seems like no macOS or clang builds reported before) |
|
Same system, MinGW build: clang: Clean build:Null build 1:Null build 2+:Leaf build: |
|
@bruvzg - surprised the first null build built anything. That's generally a sign some dependencies specified wrong somewhere. |
|
Built on debian stable. The Build Server in a docker container, but it shouldn't matter. Build Server: Since someone might not like these numbers, here are some more realistic numbers (not really, I usually do the above). Laptop: Batch means using scons with verbose=yes and capturing the output. Something like this: My two cents, probably what everyone already knew: annoyingly slow on old (but still capable) hardware. All right on a not so old low-end machine. When developing, linking time dominates scons time. |
|
You should also add |
|
For me, scons doesn't seem such a big issue for this project at this time. If and when godot switches to using dynamic libraries for its components, and possibly starts using pre-compiled headers, things will be different. Now? Meh. When changing a single cpp file, scons is taking 4s out of 28s. Touch just a header file, and compile+link time is going to trounce any time spent in scons. Now, for the way I like to work 4s-10s, let alone 2mins, would be too much anyway, but, at this stage, scons is a non-issue, unless switching build system make it easier to solve the above. |
|
Closing as this is pretty old now. We've made good progress over the years, both upstream and in our Godot configuration, to increase the speed of both clean rebuilds and incremental builds. For extra oomph, consider using Pyston and Mold on Linux, or recent SCons' experimental Ninja support, which is included in Godot's |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Preamble: This issue is focused on analyzing and (possibly) improving the performance of Godot's buildsystem configuration with SCons. We're not interested in any other buildsystem in the context of this issue, so unsolicited injunctions to "use <some other trendy build tool>" will be moderated away. The core developers' position hasn't changed in years of discussions, we're most happy with SCons but would like it to be faster - that's the sole focus for this issue.
We've noticed that different contributors have wildly different performance metrics with SCons, which do not seem to scale with the host computer's capabilities. Some users seem to have "null builds" (i.e. incremental build with no change to the source code, when everything has already been built once) of more than 20 s on Linux NVME powerhouses, while others have around 5 s null builds on low-end SSDs.
This thread will be used to gather metrics on null builds and clean builds (i.e. a build from scratch after a new clone or
git clean -fxd) from contributors, so we can have a clearer picture. We've asked SCons developers @bdbaddog and @mwichmann to help us audit all this and come with recommendations/fixes to improve the overall performance and quality of our SCons buildsystem implementation.Please time clean builds and null builds locally, and report the results here.
You can also do a "leaf build", i.e. change something that will have a minor impact on the codebase and will only trigger the rebuild of a single object. I suggest doing that by modifying a docstring in
doc/classes/Node.xml, which rebuilds the generated header andeditor/editor_help.cppwhich includes it.Here are some recommendations so that we get useful results:
masterbranchtime scons p=<platform> tools=yes target=debug -j<cores>so that we all use similar optionsPlease provide the following details:
inxi -DCmSP).The text was updated successfully, but these errors were encountered: