- Forum
- Windows Programming
- How to speed up compile time?
How to speed up compile time?
Hi just wondering how I can speed up compile times. It takes about a minute every time I compile to test my program and it is getting slower and slower the more code I add. Also switching back and forth between the code editor and designer is slow too.
Are there good practices to improve compile times?
I am using Visual Studio.
Thanks a bunch.
Are there good practices to improve compile times?
I am using Visual Studio.
Thanks a bunch.
What is your compiler/IDE and OS? CPU?
Compile time is dependent on a lot of factors that giving a simple "do this" answer is likely um-possible. Especially without a lot more knowledge of your build tools.
Compile time is dependent on a lot of factors that giving a simple "do this" answer is likely um-possible. Especially without a lot more knowledge of your build tools.
Last edited on
On my main development machine -- Win 10 Pro, i5-2400 4 core, Visual Studio 2022 Community, I have yet to have any single project take as much time as you experience. 15 seconds or less is my usual time.
The only time compiling takes more than a minute is when I do a batch build.
The only time compiling takes more than a minute is when I do a batch build.
- Don't have monster source files containing all the code.
Incremental compilation works best when you have many small source files, each dedicated to a single purpose. When you change only one file, only that one gets recompiled.
Large files are also heavy for the editor to deal with as well, so that's another reason to split things up.
If you have a number of classes, then you should have "myclass.cpp" and "myclass.h" for every one of your classes. All the "myclass*.cpp" files are added to the project as source files.
Like this -> https://github.com/Parchive/par2cmdline/tree/master/src
- Don't include unnecessary header files.
Sure it's tempting to have #include everything.h just so you don't get hit by undeclared messages. But they hurt compile times.
Incremental compilation works best when you have many small source files, each dedicated to a single purpose. When you change only one file, only that one gets recompiled.
Large files are also heavy for the editor to deal with as well, so that's another reason to split things up.
If you have a number of classes, then you should have "myclass.cpp" and "myclass.h" for every one of your classes. All the "myclass*.cpp" files are added to the project as source files.
Like this -> https://github.com/Parchive/par2cmdline/tree/master/src
- Don't include unnecessary header files.
Sure it's tempting to have #include everything.h just so you don't get hit by undeclared messages. But they hurt compile times.
One obvious thing is to be judicious about what header files to include. Only include what you need - don't include loads of stuff that you don't.
Use forward declarations rather than including header files where you can. Particularly within header files.
Keep header files as trim as possible. Remember, every line of code in a header, is a line that gets recompiled for every single translation unit that it becomes part of. As much as possible, put definitions into source files rather than header files. And to repeat myself: as much as possible, use forward declarations in header files, rather than including other header files.
Organise your code to reduce dependencies as much as possible. This particularly applies to header files - again, include only what you need, so you don't end up recompiling things you don't need to recompile when you modify a header.
Similarly, keep your link-time dependencies well organised. Watch for places where you can reduce dependencies by splitting one library into two.
Parallelise builds where possible. (VS should manage this for you, but check it's doing so properly.)
Have you tried running Task Manager during compilation? That might give you some idea whether the problem is with your PC, e.g. if the CPU is running at 100%, or if memory is maxing out, or if hard drive I/O is particularly slow.
Use forward declarations rather than including header files where you can. Particularly within header files.
Keep header files as trim as possible. Remember, every line of code in a header, is a line that gets recompiled for every single translation unit that it becomes part of. As much as possible, put definitions into source files rather than header files. And to repeat myself: as much as possible, use forward declarations in header files, rather than including other header files.
Organise your code to reduce dependencies as much as possible. This particularly applies to header files - again, include only what you need, so you don't end up recompiling things you don't need to recompile when you modify a header.
Similarly, keep your link-time dependencies well organised. Watch for places where you can reduce dependencies by splitting one library into two.
Parallelise builds where possible. (VS should manage this for you, but check it's doing so properly.)
Have you tried running Task Manager during compilation? That might give you some idea whether the problem is with your PC, e.g. if the CPU is running at 100%, or if memory is maxing out, or if hard drive I/O is particularly slow.
Last edited on
What is the language standard your projects use?
One thing I've noticed about Visual Studio and C++20 modules. The first time compiling a project is longer than any recompile afterwards. The first time your project source files are scanned for module usage and ALL modules are compiled. Including C++ stdlib modules.
Make some changes to your source files, including any custom module files you have, and the C++ stdlib modules are not part of the build.
Do a rebuild, and everything is once again scanned and compiled.
By default Visual Studio tags any .cpp file as a module interface file even when you don't use/import any modules.
Change the language standard to C++17 or C++ 14 (the only two standard available in VS) and no scanning for modules happen, speeding up the compile time.
You can still use C++20 as your language standard and manually set your C++ source files to compile as C++ code. That means you can't import modules, of course.
The type of build you do can also affect build times. Debug vs. Release. Debug can take longer.
One thing I've noticed about Visual Studio and C++20 modules. The first time compiling a project is longer than any recompile afterwards. The first time your project source files are scanned for module usage and ALL modules are compiled. Including C++ stdlib modules.
Make some changes to your source files, including any custom module files you have, and the C++ stdlib modules are not part of the build.
Do a rebuild, and everything is once again scanned and compiled.
By default Visual Studio tags any .cpp file as a module interface file even when you don't use/import any modules.
Change the language standard to C++17 or C++ 14 (the only two standard available in VS) and no scanning for modules happen, speeding up the compile time.
You can still use C++20 as your language standard and manually set your C++ source files to compile as C++ code. That means you can't import modules, of course.
The type of build you do can also affect build times. Debug vs. Release. Debug can take longer.
What version of VS? With the current VS2022 only changed functions are re-compiled. The rest are copied from previous compilation.
eg:
so don't have large, complicated functions. Split these into smaller functions.
eg:
7 of 186 functions ( 3.8%) were compiled, the rest were copied from previous compilation. 1> 3 functions were new in current compilation 1> 8 functions had inline decision re-evaluated but remain unchanged |
so don't have large, complicated functions. Split these into smaller functions.
The number of functions a project gets from the C++ stdlib depends on a couple of factors:
Compile this as C++ code using C++20 as the project's language standard and 10 functions are compiled. Compile as a C++ interface file and now 15 functions compiled.
Change the include to an import,
|
|
Compile this as C++ code using C++20 as the project's language standard and 10 functions are compiled. Compile as a C++ interface file and now 15 functions compiled.
Change the include to an import,
import <iostream>;, and now 81(!) functions need to be compiled!
A lot of people don't like to use them, but I suggest using precompiled headers IF you use a large number of STL headers or windows.h.
When I enabled precompiled headers on my project (3 libraries + main; 20-30 or so cpp files per library), it cut my compile times down from 20-30 seconds per cpp file to 1-2 seconds per cpp file. Only use precompiled headers for STL headers (and windows.h if you're using it).
If you're using 3rd party libraries, their headers can go in your pch.h file since they do not change. Do not include your project headers in the pch.h file. My libraries are sequentially dependent, so parallel compiles is not an option.
Pre-compiled headers can be a little tricky to setup. The MS documentation is a reference only and does not give examples.
1) Create a pch.h header that contains the STL headers you need and windows.h if you need it.
2) Create a pch.cpp file the contains only #include "pch.h"
3) In the settings for the pch.cpp file, set precompiled headers to "CREATE'
4) In the settings for your project, set precompiled headers USE
5) Make sure the #include "pch.h" is the first line of every .cpp file
6) Compile pch.cpp, then compile your project.
The saving in compile time will be significant if you use a large number of STL headers.
Probably not worth it if you use only 2-3 STL headers. If you need to add an STL header,
add it to pch.h header, then compile pch.cpp again. If you're using VS's build tool, this is done automatically.
When I enabled precompiled headers on my project (3 libraries + main; 20-30 or so cpp files per library), it cut my compile times down from 20-30 seconds per cpp file to 1-2 seconds per cpp file. Only use precompiled headers for STL headers (and windows.h if you're using it).
If you're using 3rd party libraries, their headers can go in your pch.h file since they do not change. Do not include your project headers in the pch.h file. My libraries are sequentially dependent, so parallel compiles is not an option.
Pre-compiled headers can be a little tricky to setup. The MS documentation is a reference only and does not give examples.
1) Create a pch.h header that contains the STL headers you need and windows.h if you need it.
2) Create a pch.cpp file the contains only #include "pch.h"
3) In the settings for the pch.cpp file, set precompiled headers to "CREATE'
4) In the settings for your project, set precompiled headers USE
5) Make sure the #include "pch.h" is the first line of every .cpp file
6) Compile pch.cpp, then compile your project.
The saving in compile time will be significant if you use a large number of STL headers.
Probably not worth it if you use only 2-3 STL headers. If you need to add an STL header,
add it to pch.h header, then compile pch.cpp again. If you're using VS's build tool, this is done automatically.
Thanks a lot for all the advice.
I am using Microsoft Visual Studio 2019.
My computer specs are...
Windows 10
i7 920 2.67Ghz
12 megs of RAM
a ssd
I use the Start Without Debugging option. What is a 'Batch build"?
I think I'm using the latest standard ?
CPU usage is 20-35%
oh and there is 2 projects in my solution.
I am using Microsoft Visual Studio 2019.
My computer specs are...
Windows 10
i7 920 2.67Ghz
12 megs of RAM
a ssd
I use the Start Without Debugging option. What is a 'Batch build"?
I think I'm using the latest standard ?
CPU usage is 20-35%
oh and there is 2 projects in my solution.
Last edited on
Win 10 x64 or x86?
If you have a 64-bit CPU consider getting VS 2022. IT is much better than 2019. Your "takes a long time to compile" experience is not gonna happen.
What is batch build? With VS 2019 or VS 2022 you can created 32-bit and 64-bit builds, debug and/or release. A batch build is one that can do 2 or more builds with one command. I routinely build any apps for both 32- and 64-bit.
From the menu: Build -> Batch Build. That brings up a dialog to let you select what you want to build: Debug, Release, Win32, x64.
If you have a 64-bit CPU consider getting VS 2022. IT is much better than 2019. Your "takes a long time to compile" experience is not gonna happen.
What is batch build? With VS 2019 or VS 2022 you can created 32-bit and 64-bit builds, debug and/or release. A batch build is one that can do 2 or more builds with one command. I routinely build any apps for both 32- and 64-bit.
From the menu: Build -> Batch Build. That brings up a dialog to let you select what you want to build: Debug, Release, Win32, x64.
Cool thanks for the tips. I am using 64 bit.. I am worried that my project will break if I update the visual studio.
Btw off topic… what happened to dreamincode.net ? It appears to be down.
Btw off topic… what happened to dreamincode.net ? It appears to be down.
Your project won't break if you install and use VS 2022. You can have 2019 and 2022 installed "side by side" if you want and have the HD space. Both will be usable.
You can load your solution file into 2022 and it will optionally perform a one-way upgrade to 2022. Once upgraded the solution will no longer be usable in 2019. Not that that is a bad thing.
Until recently I had both 2019 and 2022 installed. I realized I no longer used 2019 so I uninstalled it.
I routinely have multiple projects contained within a single solution. Let's say you are creating a DLL and a program that uses that DLL. Batch building is useful for that, so both are kept up--to-date.
You can load your solution file into 2022 and it will optionally perform a one-way upgrade to 2022. Once upgraded the solution will no longer be usable in 2019. Not that that is a bad thing.
Until recently I had both 2019 and 2022 installed. I realized I no longer used 2019 so I uninstalled it.
I routinely have multiple projects contained within a single solution. Let's say you are creating a DLL and a program that uses that DLL. Batch building is useful for that, so both are kept up--to-date.
Build/Build Solution will (re)compile all those projects in the solution that need to (re)compiled. /Rebuild will compile all projects in the solution There are also build options to (re)compile selected projects or just the current project. Note that a project is only re-compiled if a source file for that project has changed - unless rebuild is used.
Topic archived. No new replies allowed.