Did you test without unity builds, only using the JUCE headers in the PCH? Any idea what the speedup from that was? I would have thought most of the compile overhead was in instantiating templates which as far as I’m aware isn’t cached by PCH?
I did a bit of an investigation a year or so ago in to removing the global #include <JuceHeader.h> and only including the required module headers in each translation unit and it didn’t really give much improvement. I thought at the time that was probably due to the the modules being pretty heavily weighted to the common ones which were required by almost all translation units anyway.
Yeah, with PCH only i still get around 70% compile time reduction.
I can see that using PCH with a couple of juce-modules and some of our own modules results in a 700MB binary file in the build folder from the pch, so I guess that the intermediate format that the PCH uses also speeds up the compilation of templates!
Hey @vallant – just curious, what IDE are you using? I’ve switched on unity builds & PCH in my projects however it absolutely obliterates Xcode’s static analysis performance. I’m using CLion as a my daily driver, but Xcode is much much better for profiling and for doing actual runtime debugging inside the DAW – wonder if you’ve noticed this as well?
I reached out to apple and they said enabling defaults write com.apple.dt.Xcode IDEIndexShowLog 1 will let us view the static analysis reports, which confirmed that the issues stemmed for these.
I’m mainly developing on Windows using CLion and its bundled LLDB, and Intel VTune for profiling. When on Mac, I also use CLion and bundled LLDB, while for profiling I mainly use the tools provided by XCode.
I didn’t really compare the debugging performance to be honest, I just noticed that CLion by itself is using a looot of memory at times, so maybe this is why you are seeing this difference!
I actually limited the amount of memory CLion could use in its setting, otherwise my PC sometimes froze.
