Speed up compiling

[patowen]

I'm not sure whether there is a solution too this, but compilation for me is really slow. I don't know whether it is just that g++ links slowly or that something is wrong with the program. Whatever the reason, if there is a way to fix it that doesn't break anything, it would be nice.

Example: As a test, In Game::Implementation, changing unsigned short m_targetFrameRate from 60 to 61 compiled in 1 minute and 14 seconds on my computer. Changing it back (as a second test run) took the exact same amount of time.

If I make no changes at all, compiling took around 6 seconds. That also seems rather long considering that the program should only be checking the modification dates of files, but if there are a lot of files and the files are scattered across the hard drive, I can see it taking this long.

But for the 1 minute and 14 second compiling, I hope there is a way to fix that. If there is not, feel free to close the issue, but I feel like as the project gets bigger and bigger (more than just the cell stage), compiling is only going to take longer and longer.

Suggestion: Perhaps there is some optimization going on during the linking phase that takes a while. Is there a flag to disable that?

[jjonj]

I don't really have much experience with compiling large C++ projects, but i know that it is notorious for long compile times!
I don't have enough understanding of the build system to suggest anything concrete, but i wouldn't get my hopes too high.

[patowen]

That's what I feared. What bothers me is that only one object file is being compiled (or at least should be). I thought that the linking phase would be much faster since there would be no need for as much optimization, but I am only speculating here, as I can see reasons for linking to be just as complicated. I'm going to make a minor change to the code, install, and see where the bottleneck is.

(Wishful thinking below. Ignore if you want)

Ugh. I wish we could code in Java. It would make everything so much easier. It can be as fast or faster than C++ thanks to just-in-time compiling. Unfortunately, garbage collection can be the source of unacceptable lag spikes, and for that reason, we have to deal with the woes of C++ compiling. If only there were a free language to code in that modified itself quickly like Java but had C++-like memory allocation and deallocation.

[patowen]

The following two commands seemed to take the longest time. It seems like linking all the libraries together at the end takes a while, but I don't fully understand yet. Is our program statically or dynamically linked to its libraries? If it's dynamically linked, then why is there a library linking phase like this in compile time. I'm probably just misinterpreting these commands. I'll look more into it.

Also: what, exactly, is RunTests.exe?

Commands below:

C:\MinGW\bin\g++.exe -std=gnu++0x -g -Wl,--whole-archive CMakeFiles\RunTests.dir/objects.a -Wl,--no-whole-archive -o RunTests.exe -Wl,--out-implib,libRunTests.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libThrive.a contrib\googletest\libgtest_main.a C:\MinGW\install\lib\libboost_chrono-mt.dll C:\MinGW\install\lib\libboost_date_time-mt.dll C:\MinGW\install\lib\libboost_filesystem-mt.dll C:\MinGW\install\lib\libboost_thread-mt.dll C:\MinGW\install\lib\libboost_system-mt.dll C:\MinGW\OgreSDK\lib\debug\libOgreMain_d.dll.a C:\MinGW\OgreSDK\lib\debug\libOIS_d.dll.a C:\MinGW\install\lib\libBulletDynamics.a C:\MinGW\install\lib\libBulletCollision.a C:\MinGW\install\lib\libLinearMath.a C:\MinGW\install\lib\libBulletSoftBody.a contrib\luabind\src\libluabind.a contrib\lua\liblua.dll.a -lm contrib\googletest\libgtest.a -lpthread -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

C:\MinGW\bin\g++.exe -std=gnu++0x -g -Wl,--whole-archive CMakeFiles\Thrive.dir/objects.a -Wl,--no-whole-archive -o Thrive.exe -Wl,--out-implib,libThrive.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libThrive.a C:\MinGW\install\lib\libboost_chrono-mt.dll C:\MinGW\install\lib\libboost_date_time-mt.dll C:\MinGW\install\lib\libboost_filesystem-mt.dll C:\MinGW\install\lib\libboost_thread-mt.dll C:\MinGW\install\lib\libboost_system-mt.dll C:\MinGW\OgreSDK\lib\debug\libOgreMain_d.dll.a C:\MinGW\OgreSDK\lib\debug\libOIS_d.dll.a -lpthread C:\MinGW\install\lib\libBulletDynamics.a C:\MinGW\install\lib\libBulletCollision.a C:\MinGW\install\lib\libLinearMath.a C:\MinGW\install\lib\libBulletSoftBody.a contrib\luabind\src\libluabind.a contrib\lua\liblua.dll.a -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

[bkloster]

Unfortunately, there's no easy fix for that. It's mostly an issue with MinGW for Windows, which is notoriously slow, especially with linking. The test you mentioned (recompiling only game.cpp) takes me 25 seconds for native Linux compiling, Cross compiling from Linux to Windows with MinGW takes 18 seconds (no idea why it's faster).

RunTests.exe runs a suite of unit tests for stuff that is easy to test. We could add an EXCLUDE_FROM_ALL to the cmake command for generating the RunTests executable so that it's not produced by default.

[patowen]

I doubted that there would be an easy fix. The weird part is that the longest part of the linking phase, at least for me, is when the program links the ".a" libraries together. Why does that phase even exist at all if the executable ends up depending on several dlls anyway? What is being linked?

[jjonj]

I'm closing this as it isn't an actual issue but rather something that will always be useful to achieve.