10 hours ago, ChaosEngine said:That said, for a 320 line file, it should be fine.
320 lines of code in the main C++ files, and however many thousands lines of code are directly and indirectly included. The code in the actual C++ file is rarely the main culprit when it comes to slow compile speeds.
On 10/10/2019 at 7:30 PM, Acosix said:8 RAM is a lot. So is 3.2 GHz
On 10/11/2019 at 8:43 AM, ChaosEngine said:3.2GHz i5 is fine, but not excessive. 8Gb is definitely on the low side.
Thank a lot, Acosix and ChaosEngine. It is very useful advise.
On 10/11/2019 at 7:53 PM, a light breeze said:.... however many thousands lines of code are directly and indirectly included. The code in the actual C++ file is rarely the main culprit when it comes to slow compile speeds.
Yes, absolutely true. I found no automatic tool that count all lines indirectly included though. >.<
3 hours ago, hyyou said:
Thank a lot, Acosix and ChaosEngine. It is very useful advise.
Yes, absolutely true. I found no automatic tool that count all lines indirectly included though. >.<
gcc and clang support the -E option to preprocess a source file without compiling. By checking the output, I can easily see that (for example) #include <iostream> by itself yields 28138 lines of code on my computer!
19 hours ago, a light breeze said:#include <iostream> by itself yields 28138 lines of code on my computer!
That is a stunning figure. I will be more careful about #include.
Thanks, a light breeze!
On 10/10/2019 at 12:36 PM, Bregma said:My next guess is that you're using template-heavy code. It's going to increase compilation times. Header only libraries and template-heavy code go hand-in-hand, and both are compile-time performance killers
That is a very good candidate. Are you using any std related stuff?
Instead of workarounds try to locate the real problem. if your cpp file is not that big, try removing parts of it (code/include/both) and see what happens. 40 sec is way too much for a single file. It should be enough to full-rebuild a half million line code base, without unity build 
18 hours ago, Alessio1989 said:Did OP tried to use a pre-compiled header?
Thank. OP (me) uses it.
1 hour ago, bmarci said:On 10/10/2019 at 5:36 PM, Bregma said:My next guess is that you're using template-heavy code. It's going to increase compilation times. Header only libraries and template-heavy code go hand-in-hand, and both are compile-time performance killers
That is a very good candidate. Are you using any std related stuff?
Thank.
Yes, I do #include <sstream> for printing log. It is included as the top header. I don't use Boost.
Most other libraries I used are created by custom, e.g. I use my own MyArray<T> instead of std::vector<T>, and custom MyPtr<T> (probably direct+indirect ~400 lines) instead of just T*.
I don't know how to measure/profile compile-time penalty I get from template. I am using Visual Studio.
Probably made the mistake of #including windows.h... 
One of the tricks I use for non-template external libraries / functions that have 'expensive' includes, is to wrap them in your own .h / .cpp file. So you only include your own .h to use the functions rather than the third party. Yours can be clean and fast compiling, even if the external is rubbish.
E.g.
//my_windows_wrapper.h
#pragma once
#ifndef QUICK_BUILD
#include <windows.h>
#endif
class WinWrapper
{
public:
#ifdef QUICK_BUILD
void some_windows_func();
#else
// will get optimized out
void some_windows_func()
{
// call windows
some_dodgy_windows_func()
}
#endif
};
//my_windows_wrapper.cpp
#include "my_windows_wrapper.h"
#ifdef QUICK_BUILD
#include <windows.h>
void WinWrapper::some_windows_func()
{
// call windows
some_dodgy_windows_func()
}
#endifThen for final release you can change the QUICK_BUILD define and it will link directly to the third party code. There might be an even better way of doing this.
Optimizing compile / link times can be really important in big projects to reduce iteration time, and there's no reason why you can't do it at zero cost for final release builds.
28 minutes ago, lawnjelly said:One of the tricks I use for non-template external libraries / functions that have 'expensive' includes
Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP?
// service.h
#pragma once
class ServicePayload { ... };
class Service {
public:
void send_operation(ServicePayload const &);
void default_operation(void);
};
// common/service.cpp
#include "../service.h"
void Service::default_operation() {
ServicePayload basic( /* ... */ );
send_operation(basic);
}
// windows/service.cpp
#include "../service.h"
#include <windows.h>
void Service::send_operation(ServicePayload const &p) {
// ...
}
// linux/service.cpp
#include "../service.h"
#include <iostd.h>
void Service::send_operation(ServicePayload const &p) {
// ...
}... and then always link against common/*.o, and link against only windows/*.o or linux/*.o depending on which EXE you're building.
8 hours ago, lawnjelly said:Probably made the mistake of #including windows.h...
7 hours ago, Wyrframe said:Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP?
Thank, lawnjelly and Wyrframe. I already separated <window.h> to .cpp.
My problematic cpp file does not #include <window.h> neither directly nor indirectly (I just check it), but your advises (and JoeJ's) make me realize that I really should enable "C/C++>Advanced>Show Includes" compiler log. Thanks.
