Compiling time

Started by Garwin, 01 May 2022, 02:39:46

Garwin

Finally adding TGUI code to my first game.
However, I am quite surprised that it change compiling time significantly.

Before adding TGUI, it takes 3-4 seconds to compile.
After adding just declaration of tgui to one of my classes:

#include <TGUI/Core.hpp>
#include <TGUI/Backend/SFML-Graphics.hpp>
#include <TGUI/Widgets/Button.hpp>

tgui::Gui m_gui;


And the compilation time increased to 79 seconds even with commenting out all other TGUI staff.
Is it OK such increase of compilation time? Especially with the notes below?

note1: Codeblock GCC 7.3.0
static linking of SFML and TGUI

note2: for my previous testing I used dynamic linking of SFML and TGUI and it takes only 3 seconds to compile.

texus

#1
That doesn't sound normal. Up to a few seconds more compilation time (potentially multiplied with every source file that includes TGUI) and up to several seconds of additional linking time might occur in worst case, but over a minute is far too long. Since there shouldn't really be a difference between static or dynamic linking, especially the compilation time of the source files should be identical, you should see the same slowdowns when linking dynamically though.

The Build Log at the bottom of CodeBlocks will tell you which file is being compiled and when it is linking the executable. The first thing you might need to do is check if the linking step that is taking more than 10s, or whether the majority of the time is spend on compiling files.

In 79 seconds you can compile the entire TGUI library, are you certain you aren't compiling the TGUI source files with your project?
And you didn't enable Link Time Optimization (which would add a significant amount of time to linking)?
Are those TGUI headers being included in a single source file, or in a header file that is included in many source files?

Garwin

#2
Issue is that this information is not included in the builder log (enclosed).

I check all the project setting, no issues find (debug version).

Compiler flags:
-std=c++17
-static-staticlibgcc-static-libstdc++
-g
-Wall

Defines:
SFML_STATIC
TGUI_STATIC


Linker settings:
tgui-s-d
sfml-graphics-s-d
sfml-window-s-d
sfml-system-s-d
opengl32
freetype
winmm
gdi32

Search directories (compiler):
...\project itself\include
...\SFML\include
...\TGUI\include

Search directories (linker):
same - only instead include there is lib

Custom variables:




Another strange thing is that the file is too large, going from about 10 MB to over 50 MB.
Everything is fast except final "rows" from output file.


EDIT:
changing to dynamic linking makin the compiling only 3 seconds and 6 MB file size. So it seems that it really must compile whole TGUI library, but I cannot see what setting did it.

texus

#3
50MB is normal for a debug version. Just the "libtgui-s-d.a" is 91.6MB (while the release version is less than a 10th of that size). Dynamic linking results in smaller exes because it keeps all the external code in the DLL instead of including it into the exe.

Did you build SFML and TGUI yourself using the "SFML_USE_STATIC_STD_LIBS=TRUE" and "TGUI_USE_STATIC_STD_LIBS=TRUE" options?
Because the default static SFML and TGUI versions link dynamically to libgcc and you thus shouldn't have "-static", "-static-libgcc" and "-static-libstdc++" in your linker settings.

The build log does tell you when you are compiling and linking, but I just tried it here and it is less useful than I thought.
All the lines starting with "g++.exe -std=c++17" are telling you that it starts compiling a source file (at the end of the line you can see which source file). These lines can print very quickly when building with multiple threads, as it will start compiling multiple files in parallel.
The last "g++.exe" line which is longer than the rest and ends with all those "-lXXX" options is when it starts linking the executable.
I was surprised that it is printing compiler warnings AFTER the linking step. All compiler warnings should happen before it starts linking. But I tested it here and this seems to be normal when you don't explicitly set the number of parallel builds to 1. And while the text is outputted in the correct order when doing so, it's still hard to follow what it is doing in realtime.

At the end of the build log it states "Process terminated with status 1", which means it FAILED (it should end with status 0 normally). Did you manually stop the build? Because if you didn't do anything then I think it might have crashed (which would be weird if it does still generate a functional exe).

Garwin

#4
QuoteDid you build SFML and TGUI yourself using the "SFML_USE_STATIC_STD_LIBS=TRUE" and "TGUI_USE_STATIC_STD_LIBS=TRUE" options?
Because the default static SFML and TGUI versions link dynamically to libgcc and you thus shouldn't have "-static", "-static-libgcc" and "-static-libstdc++" in your linker settings.

No, I used the ones on the TGUI page only trying to change dynamic linking to static linking as I wanted to evade having all libraries in 2 folders (debug and release).
I will try to switch it off. Quite strange is that before adding TGUI to the project I have already SFML with static linking and it works fine which is contradict to what you say that both SFML and TGUI libraries are linked dynamically to libgcc.
I will probably switch back to dynamic linking it seems so far the easiest solution as a newbie I do not want to go through all the compiling issues with cmake yet, but probably after finishing my first simple game.

QuoteAt the end of the build log it states "Process terminated with status 1", which means it FAILED
It can be as I was trying different thing and I may copy there the wrong log.


EDIT:
I used this linker setting on top all settings:
..\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\7.3.0\libstdc++fs.a

I use experimental filesystem as I found out that in this version of gcc this c++17 feature is implemented only as experimental as I use generic approach of loading textures as whole directory with logging it to log file without specifically mentioning name of textures.