I've installed Godot on Ubuntu from the repos and it was using about 10-20% of the CPU. Now I've made my C++ module and have built Godot from source, and it's using 100% of both cores just sitting there opened (not even any project open, just in project browser). These are arguments I've fed to SCons:

platform = "x11"
tools = "yes"
target = "release_debug"
bits = 64
use_lto = "yes"
udev = "no"

I'm building without my module so I can check if it's its fault... it isn't. Am I doing something silly?

    building godot 4.0 took me like 15 mins with 8 cores @4.5ghz at 100%, so I guess it would take a while with relatively old hardwares.

      Probably because it's a debug build, those can be slower. Also the Godot on the repo is super old and should not be used. Download from the website to test performance with the latest stable version.

        capt_sms Now I've made my C++ module and have built Godot from source, and it's using 100% of both cores just sitting there opened (not even any project open, just in project browser)

        Something(tm) is wrong, but without knowing more it is anybody's guess.

        Are "the repos" a cloned branch from github ?. For reference, I am on Godot 4.0 beta, compiling with debug symbols takes around 10min with 16 threads. The Editor then runs with a CPU use of 1% to 2%, a small project open.

          The version of Godot on Ubuntu repo is 3.2.3 which came out over 2 years ago. If you compile from source, you are getting the latest master branch, which could be entirely broken.

          Most likely you want to pull the latest stable branch, which I believe is 3.5.1 and then test that versus the 3.5.1 binaries from the Godot website. In any case, if you are building in debug mode it won't be the same speed.

          Didn't know Ubuntu (and even Debian!) have a Godot version in the repositories :-)

          From github you choose the branch. If nothing, master (4.0) is the default.
          You can have several branches (for example 3.5 and 4.0) side by side, in different directories.

          You can also pull tags, there should be one for 3.5.1-stable. This is the best idea if you are making plug-ins or that type of thing.

          git clone https://github.com/godotengine/godot.git -b 3.5.1-stable

          MagickPanda I'm talking about using the engine, not building it.

          cybereality I've set target to "debug_release" which is the lowest allowing for tools ("release" is w/o editor), so Godot from the repo needs to be "debug_release" too, no? I'm was using "debug" before and saw the warning about performance, but later I've switched to "debug_release" and it ceased to show up, so I think I'm good here, I was using branch "3.x", now I've used "3.5.1-stable" tag, but it's still the same problem (it has built as "3.5.1-stable-custom_build.6fed1ffa3" which kinda fits the "6fed1ff" of the tag). My executable is godot.x11.opt.tools.64, so release and stable now, but still uses 100% of both cores...

                capt_sms Sorry I tought you were building it on ubuntu. I guess your problem might be some rendering is falling back to cpu, how you tried setting active window to 'script' tab to see if the cores load drops?

                    I just rebuilt the client using my gentoo ebuild and it's running about 4-6% cpu on my old walmart laptop. The scons command portage uses is

                    scons -j8 extra_suffix=main AR=x86_64-pc-linux-gnu-ar CC=x86_64-pc-linux-gnu-gcc CXX=x86_64-pc-linux-gnu-g++ platform=x11 progress=no verbose=yes deprecated=no minizip=yes pulseaudio=no udev=yes system_certs_path=/etc/ssl/certs/ca-certificates.crt builtin_bullet=no builtin_certs=no builtin_embree=no builtin_enet=yes builtin_freetype=no builtin_libogg=yes builtin_libpng=no builtin_libtheora=no builtin_libvorbis=no builtin_libvpx=no builtin_libwebp=no builtin_mbedtls=no builtin_miniupnpc=no builtin_opus=no builtin_pcre2=no builtin_recast=no builtin_rvo2=yes builtin_squish=yes builtin_wslay=no builtin_xatlas=yes builtin_zlib=no builtin_zstd=no module_bullet_enabled=yes module_mono_enabled=no module_ogg_enabled=no module_opus_enabled=no module_raycast_enabled=yes module_theora_enabled=yes module_upnp_enabled=yes module_vorbis_enabled=no module_webm_enabled=yes module_webp_enabled=yes debug_symbols=no optimize=none use_lto=no use_static_cpp=no target=release_debug tools=yes

                    The source is at

                    https://downloads.tuxfamily.org/godotengine/3.5.1/godot-3.5.1-stable.tar.xz

                      duane I've used most of your options (had to install a lot to counter missing headers all of sudden, probably all the modules you selected), and it's still the same: repo version works fine, built from source - using all cores, lags... 🙁 I couldn't use builtin_recast=yes because although I've installed librecast-dev, I'm getting "Recast.h is not a file or a directory" error. I also coudn't use builtin_wslay=yes, similar reason with libwslay-dev. Are these important?

                          capt_sms

                          It's possible that an included library is a problem, but I doubt it, so the builtin_* parameters probably won't help. Are you running the executables both the same way, in the same environment (and not simultaneously)? Are they using the same memory? Have you tried building with clang?

                              capt_sms hmm maybe the only way to solve this puzzle is to use a profiler to find out which functions use most cpu time

                                  You might also post your build log.

                                  @capt_sms . Besides posting the output of the building process, can you post the artefact with debug symbols ? Want to try an run it, kernel 6.0.0.2.

                                  Before doing so, I repeat the question: You have the 3.5 branch from github, this one, right ?

                                    Thank you guys for your continued support!

                                    duane I didn't try Clang because of this: "It's still recommended to use GCC for production builds as they can be compiled using link-time optimization, making the resulting binaries smaller and faster." But I will try everything now, so adding to the list.

                                    Same environment, I don't run them at the same time.

                                    Each run uses two processes, 3.5% memory usage each for repo, 4.7% for built, very similar for 4G RAM.

                                    Command to run is just a path to the exec file, for both.

                                    Also, forgot to mention, I've built the Godot the same way on Fedora current version and it works fine, but that's also much more powerful machine so I might just not see the difference... but it takes 0.2% of one core here, both built and from repo, so I doubt it, it has to be software. Now I'm trying to build the same thing on Lubuntu LTS and these problems showed up. I've just installed Fedora on my old laptop, it also works fine there...

                                    Build log:
                                    The config.py file with all the build arguments:

                                    MagickPanda I don't think I know how to do it... I was using profiler in Qt Creator once, I know what that is, but I don't know about SCons.

                                    Pixophir it's 3.5.1-stable from the github tag, but even worse than with profiling, "artefacts with debug symbols" don't tell me much, and it's so hard to google anything about SCons...

                                            Artefact refers to the executable. I could check out the Linux executable on a very old very slow notebook with a two core intel i3 and hd4400 graphics. Provided I get it updated to the current kernel ...

                                            From what you describe, my bet is on problems with the machine and its configuration were the phenomenon occurs.

                                            capt_sms

                                            Your build log didn't produce the output I was expecting. If you get a chance, could you run it with stderr redirected as well?

                                            scons ... |& tee build_log.txt