Prototype: Precompiled headers for Visual Studio

Dear all,

Enclosed is a diff format patch for the current (as of this writing) Projucer that permits you to export Visual Studio projects that make use of precompiled headers.

A lot of people consider precompiled headers to be ugly. I don’t care about ugly. The performance benefit for precompiled headers during compilation of large projects is significant. I’m able to cut my compile times by a large percentage with precompiled headers produced by this patch.

Using precompiled headers on Visual Studio requires some setup.

To use this patch, create a precompilable hpp file, which #include’s the majority of large library headers for your project. I’ll call mine precompiled_header.hpp:

// precompiled_header.hpp
#include “windows”
#include “juce”
#include “whatever-other-slow-includes-you-want”

Now create a precompiled_header.cpp file and add it to your project. The base name of the file must match the base name of the precompiled header file. The precompiled_header.cpp file must contain exactly one line:

// precompiled_header.cpp
#include “precompiled_header.hpp”

Now include this precompiled_header.cpp file in your project.

In the Exporters section of the Projucer, select the Visual Studio exporter for the version you’re using. Select the “Use precompiled headers” checkbox, and also type in the name of the precompiled header file – in this example, precompiled_header.hpp.

Save and export your project to Visual Studio solution file, open the solution file in Visual Studio, and hopefully you should enjoy much faster compile times. In particular, you will note that precompiled_header.cpp is compiled first, and then the rest of the .cpp files are compiled much more quickly, as though precompiled_header.hpp has been appended to the top of each .cpp file.

It should be straightforward to port this patch to JUCE’s other targets. I may take a crack at MacOS soon.

Precompiled headers are not a magic bullet for slow compilation. But used judiciously, precompiled headers can help save your sanity on big projects.

patch.diff.txt (9.7 KB)

1 Like

If the Visual Studio settings are set properly, it is not necessary to include precompiled_header.hpp in each .cpp file. Visual Studio will pass /FI precompiled_hearder.hpp to MSVC, which includes precompiled_header.hpp automatically (see https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file for more details). You still need precompiled_header.cpp, but it can be empty.

McMartin, you are correct. It was a one-line change to add your idea to this patch, so I went ahead and added it to the patch above. Others, if this doesn’t fit your requirements, you’ll see the single added line at the top of the diff.

This is all good stuff, but wondering why JUCE on win and OSX doesn’t support precompiled headers out of the box? Maybe a JUCE dev can comment?

1 Like

@ed95 Hi Ed - can someone comment on whether this is on the road map at all? Using pch on windows/macos can drastically reduce compile times for us when not using modules.

reducing compile-times is a top productivity enhancement. How much faster is working with precompiled headers?

1 Like

If my measurements are correct, it also reduce heavily compile time when using modules.

I was able to reduce the compile time in a big plugin project for 2minutes to 30 seconds, for the SharedCode project only.
The project uses a lot of source files, which separately including the JuceHeader.

This is substantial and a must have for the Projucer, because it makes the life of a developer simply more pleasant, isn’t it important?

@jules can we have PCHs (optionally) in the ProJucer?

PS:
I had to exclude the include_*cpp files from the force include and the PCH generation, and activate x64 hosted Visual C++ toolset via environment variable, in order to prevent heap-memory limits with the compiler (because PCH uses shared memory)

1 Like

I did raise this as a question at ADC this year and Jules said there was no real reason why it hadn’t been done, other than that he’d never experienced build times that would warrant it (my Mac Mini 2014 would definitely appreciate this).

Whilst there was no commitment to add it, there was no reason not to do it, so maybe the more voices we have, the more likely it’ll get done…

1 Like

I applied the changes provided by johnwbyrd. @johnwbyrd: Thank you for providing it!
Enabling precompiled headers definitely cut my compile times too. So I would be very happy if this feature is part of the Projucer.
Despite enabling precompiled headers on project level, being able to change behaviour on file level is crucial for me. I have a few c source files included in my project and I must disable precompiled headers for these files. These changes are always lost now when I recreate my project with the Projucer. I searched for possibilities to disable precompiled headers by commands in code (e.g. pragma) but couldn’t find anything.

Best regards

Just in the situation to make a huge investment in my hardware to improve my productivity with shorter compile times (maybe 10 seconds per build), just funny I could have the same for “free”, if the projucer could automatically setup settings right for precompiled headers.

1 Like

Any update for this in 2020? Both Visual Studio and Xcode?

2 Likes

What is going on? Why is not a single JUCE maintainer commenting? Not even a “we don’t see the benefit” or “we’re looking into it”? Nothing?

This is a HUGE timesaver. Simply ignoring it would be a disservice to ALL JUCE users.

3 Likes

I can’t comment on PCH support in the Projucer, but CMake has supported target_precompile_headers since version 3.16. Now that JUCE can be built with CMake, this is a potential way to add PCH to JUCE projects.

1 Like

I’ve brought this up on at least 2 occasions before and both times it’s been met with “yes, we can do that” and then nothing.

i guess so, but I’m not intending to move over to cmake, and there’s really no reason this can’t be added to Projucer.

1 Like

I agree.

Any comments? @jules @t0m @fabian @dave96

3 Likes

i see tumbleweed

@jules, @t0m, @ed95

Hi - I know you’re all busy guys but at least some response to this would be nice.

No comment after tagging speaks for itself unfortunately

I know, a bit disappointing really.