Improve building time
Have a lot of functions, which placed before main
If I move it inside main, will it affect building time?
If I move it inside main, will it affect building time?
My guess is that it won't make much of a difference.
Are you actually having problem with long build times or are you just trying to optimize prematurely?
Are you actually having problem with long build times or are you just trying to optimize prematurely?
Last edited on
Don't do big rebuilds, let the tool decide to build only what changed until its fully debugged and ready for release. The program I work on takes 30+ min to build from scratch and about 30 seconds for changes only.
> Have a lot of functions, which placed before main
> If I move it inside main, will it affect building time?
If you move them into separate files, it will improve build time.
If you have a single file "ball of mud" for your source code, then regardless of the size of the change, you have to recompile all of it.
But, if your main program features are separated out into different source files, then the relatively expensive compilation only happens on the file you edited.
> If I move it inside main, will it affect building time?
If you move them into separate files, it will improve build time.
If you have a single file "ball of mud" for your source code, then regardless of the size of the change, you have to recompile all of it.
But, if your main program features are separated out into different source files, then the relatively expensive compilation only happens on the file you edited.
If you're using the latest VS, for a normal build it only re-compiles functions that have changed. So their location in the same compilation unit doesn't matter. After compilation it gives a summary of the number of functions and the number compiled. So for a fast compilation have lots of small functions - the fewer and the smaller the functions that need to be re-compiled after changes, the faster the re-compilation.
Breaking down your project into separate (sub)functions generally is a good idea, as it makes your code more readable, more easy to maintain and more easy to re-use. It also avoids pointless "copy & paste" code. Conversely, merging everything into the
Really, whenever you spot a block of code that could be refactored/generalized into a separate function, then take your time and do it 😏
In order to reduce compilation time, you should split your functions/classes into a number of separate compilations units – i.e. separate
main() function would only create messy "spaghetti" code that is hard to understand and hard to maintain. So, better do not do this!Really, whenever you spot a block of code that could be refactored/generalized into a separate function, then take your time and do it 😏
In order to reduce compilation time, you should split your functions/classes into a number of separate compilations units – i.e. separate
.cpp files with corresponding .h files. This way, every time your build your application, only the .cpp files that actually have changed will be re-compiled. All other .cpp files do not need to be re-compiled (unless you force a full re-build), which can save a lot of time!
Last edited on
Furthermore, separate compilation units can be compiled simultaneously, saving a bit more time.
Can the VS do that with one compilation unit?
Although, if you do modify a header that is included in multiple .cpp, then they all have to be recompiled because "they" have changed. Therefore, the less you absolutely have to include, the better.
Can the VS do that with one compilation unit?
| only the .cpp files that actually have changed |
Although, if you do modify a header that is included in multiple .cpp, then they all have to be recompiled because "they" have changed. Therefore, the less you absolutely have to include, the better.
Last edited on
Topic archived. No new replies allowed.