• 9
• 9
• 10
• 10
• 9

# What to do besides fencing?

This topic is 527 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

What do you do when the project takes a long time to build? :). 15 min build time here so it has been much cppcon on youtube :).

##### Share on other sites

I like to randomly strip out sections of code to see if it improves the build times.   :)

Sometimes it's so fast, it's as if it doesn't even build at all!

Edited by xycsoscyx

##### Share on other sites

You could try the so called unity builds, or including few cpp files in one file to reduce the amount of code that is being parsed.

so

Texture.cpp.inl Buffer.cpp.inl Shader.cpp.inl and you create a brand new cpp
the_real_cpp.cpp that containes:

#include "Texture.cpp.inl"
#include "Buffer.cpp.inl"
#include "shader.cpp.inl"

It works pretty well. Be aware of hidden global variables that my exist per translation unit. We did not have any so it went fine for us.(this is what I do for my D3D/GL wrapper classes).

Another thing that people do (but I do not approve) is precompiled headers, they surely work but in my humble experience shows that the PHC becomes a mega header that includes everything.

Additionally if you can hunt down all the includes to heavy headers like <iostream> <windows.h> <d3d11.h> and isolate them would be very benefitial.

And of course the usual "extern template-ing" and moving functions to *.cpp files, forward declaring whenever possible etc.

EDIT:

Additionally you could try converting some macros to functions and moving the implementation to a cpp file. @work we write plugins for Maya and we had a commonly used macro that checked the returned by Maya MStatus for errors. A college of mine change that form a macro to a function and that reduced the compile times by ~30%(unsed MSVC compiler, no change in gcc clang icl) so it was pretty big.

Edited by imoogiBG

##### Share on other sites

I like to go through header files, comment out all the #includes, and then add them back in only if a forward declaration won't suffice. Start with the most important headers and see if it makes a difference. The other thing is to split things out into more files, so that a higher proportion of the project files remain untouched (and thus never recompiled) during development of any single feature.

##### Share on other sites

I remember that myhandmadehero dude saying some thing like if your building time is taking more than 15 sec, doesnt matter how big is the project, youre doing something wrong, he was very enfatic in that (he wasnt just throwing words)..anyone agree with that?

##### Share on other sites

Guys, I'd already go bonkers if a full rebuild took over a minute for me =/ (and of course I normally build like after about every change so in practice it's more like 3 seconds since only one or two files need to be rebuilt)

You could try the so called unity builds, or including few cpp files in one file to reduce the amount of code that is being parsed.

so

Texture.cpp.inl Buffer.cpp.inl Shader.cpp.inl and you create a brand new cpp
the_real_cpp.cpp that containes:

#include "Texture.cpp.inl"
#include "Buffer.cpp.inl"
#include "shader.cpp.inl"

It works pretty well. Be aware of hidden global variables that my exist per translation unit. We did not have any so it went fine for us.(this is what I do for my D3D/GL wrapper classes).

I once did this but because the IDE was broken (no idea what happened) and was refusing to take my static libraries so I went the overkill way of literally #including them. Also for whatever reason it wasn't keeping track of headers so I had to do full rebuilds no matter what (it was an awfully broken install, OK?). Then I noticed that if I just had a single file that #included every other file (which happened to work in my case) the build time would go down from over a minute to like 5 seconds. I have no idea what's going on but I guess that spawning the compiler process is even worse than the compiling itself.

##### Share on other sites
Eh, it depends on what kind of build he's talking about. If it's incremental minor builds with minimal changes, sure, 15 seconds is a reasonable expectation for moderately sized projects. I don't agree that it is unacceptable to be longer in very large code bases, especially around link times.

If he's talking about a full rebuild, he's smoking crack.

##### Share on other sites

Well i was mostly after what you do when you do have some time over. But the focus here on minimizing your waiting time makes your employer proud :wub: .

For me right now the build time does not matter yet. I'm setting up a project for a team to work on. The steps includes everything from checking out, compiling, building all assets and make the tools work for each discipline. Also the documentation for it all :blink: . Each time i made a change i need to try it from the beginning as a new content developer on the team would do. Then i find a new flaw somewhere that needs to be fixed and start it all over again.

So it's more of a first time setup time. To bad i have to suffer it on repeat for a while when testing it :cool:.