Compiling Juce project with VS2010 on Windows is slow

compiling Juce project, for example 'The Introjucer 3.1.1', with VS2010 on Windows is slow, about 180 seconds;

compile a normal vs project with vs2010 on win is faster, about 7~25 seconds;

compile a normal vc project with vc++6.0 on win is faster than the above, about 4~12 seconds;


Can I compile a Juce project using Cl and Link of vc++6 ?

Or tell me which code cost the most time.



The introjucer is probably nearly a million lines of code. And 180 seconds isn't too bad for that amount - it's only that quick because juce's modules are organised into optimally-sized compile units.

But regardless of that, saying it's "slower than a normal VS project" is completely meaningless!! What on earth is a "normal" project?? For some people their "normal" projects might take 4 hours to compile!


Thanks for your reply, Jules.


i download a proj 'Look and Feel' on github

i feel JUCE is very powerful, but if it could be faster, will be better.

Hi FaizHo,

Of course, faster is always better, couldn't agree more :-) 

To be honest with you, when I started working with JUCE, one of the things that impressed me the most (apart from the code itself) is how fast JUCE apps compile compared to apps of similar complexity built with other cross-platform frameworks.

Before I joined the JUCE team here at ROLI, I worked on other frameworks and applications in the music industry, where a real-world app could literally take hours to compile. So companies would buy top-end MacPros and massive build servers for everyone in order for the team to be productive. Using JUCE, I am able to compile a synth on my laptop (!) in a couple of minutes. Personally, I have not seen anything else that performs so well at compile time for this kind of stuff, and it's one of the reasons why I am a JUCE fan :-)  Of course, at the end of the day it's up to you to decide what "fast" and "slow" and "normal" means for your use case and what you want to achieve.

Compile time varies depending on what IDE you use. You will probably get better compile times if you upgrade to Visual Studio 2015, and even better compile times if you switch to a Mac and use Xcode.

Also please consider that an app that runs fast is more important for most people than an app that compiles fast. This is the main reason why we use C++ in the first place.

Hi Timur,


Thank you for your reply ~

I agree that, an app that runs fast is more important for most people than an app that compiles fast .

Meanwhile, I stop from including some modules unused to a project, it compile faster.


But I still suggest to add an option on Introjucer/Projucer, so that let developers to choose to build a RAPID or HIGH-PERFORMANCE version.


maybe, to compile a whole project to test a small changing is silly.

but if this function was achieved, will be better, and save much time for tests.

maybe, to compile a whole project to test a small changing is silly.

That would be silly. But that's not what happens.

All IDEs/compilers will only rebuild the compile units that are affected when I file changes. If your project is rebuilding everything unnecessarily then either you're doing something silly, or something is wrong with your project or IDE settings. But it's nothing to do with juce or the projucer, because obviously we use this stuff every day and if this didn't work, we'd have sorted it out years ago.

Just an idea. Having loaded the project, and selecting Release/Debug as necc,  go and make a cup of tea while MSVS's caches are being read/created. Once all that disk actiity has subsided (and no furher project/include files) are being accessed (might take a few mnutes), you might find the build runs much (much!) quicker (I don't recall this as an issue on 2010, but I'm using 2013 and this is how it works for me)  - also, I've just got a Raspbery Pi 3 (building the whole of Juce (all projects, release and debug) takes around a day ;)

I'm looking forward to seeing if the Pi3's benchmark lves up to its name