Slow building in Visual Studio 2008


#1

Hello,

I am completely new to the JUCE framework and have just been playing about with the various example applications today. The problem is that it seems to take an excessive amount of time to build even the simple HelloWorld project. It consistently takes about 90seconds or so, which although not huuge, is enormously frustrating and kills productivity!

From a quick look at the currently running processes, it seems that most of the time is spent running link.exe

Any hints about what might be causing such a slowdown?

I am building ‘HelloWorld’ release version with VS2008 on windows XP sp3

I don’t have this trouble with non-JUCE projects in VS but admittedly I do most of my C++ programming in Codeblocks/gcc so I am pretty naive about the microsoft tools.

Thanks for any help!

Will


#2

for release builds it’s true, if you switch to Debug it’s much faster, it depends on optimization options i think.


#3

Sorry I didnt make it very clear, I meant to say that it is equally slow for both debug and release builds!

Is it just that the Juce libraries are just so massive that it always takes ages to build? Seems strange that the build process doesnt ‘cache’ the result of previous compilations - If I just change the string to be displayed in HelloWorld/main.cpp it will take just as long to build as if I had done a complete re-build

cheers for the help


#4

That sounds a bit odd - it only takes a couple of seconds for me, even though I’m running window in a VM!

Do you have a ridiculously small amount of memory, perhaps?


#5

have about a gig spare of RAM - the linker process only uses about 80megs max, it just takes sooo long!

Yeah I dont have the fastest PC but I can normally compile and run reasonably complex programs in a few seconds,

Could it be to do with the linkage method of JUCE?


#6

well i get the same thing, my project currently links a few minutes on a 2GHz dual Xeon (though the amount of cpus doesn’t matter, the speed matters the linker process does not scale across threads)
If you use the amalgamated juce library it takes that long each time you rebuild.


#7

Does it take you that long when compiling the simple HelloWorld project?

Surely that should be seen as abnormal? I would consider any reasonable project that takes over 30 seconds to compile to be a problem. It really impacts development time and will drive programmers crazy!


#8

I used the JuceDemo for tests (dual XEON E5405 (dual core with HT)@ 2.0GHz, 6GB RAM about 4GB free)

Debug of JuceDemo with /MP "Time Elapsed 00:00:24.00"
Release of JuceDemo with /MP “Time Elapsed 00:01:10.87” (most of witch is the Generating Code/Linker time)

My project same machine
Debug with /MP "Time Elapsed 00:02:44.11"
Release with /MP “Time Elapsed 00:12:36.39”


#9

Thanks for the reply - my system is fairly crappy - Pentium IV 2.8Ghz

For the Juce Demo, 1 minute 21 seconds for building debug and 2 mins 30 seconds for release

I guess this just surprised me a little - Im not used to simple demos taking so long to compile!

I will play with linking to a static Juce library, hopefully that should speed things up a fair bit.


#10

Turn off “link time code generation”. When you build your .exe for final distribution, turn it back on.


#11

I’ve been in situations where it was the virus scanner that was the issue, as it was checking every file written/read by the compiler/linker…


#12

no virus scanner on my machines.


#13

likewise I never run a virus scanner in the background


#14

You can use Process Monitor from SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb896645) to see what file activity is going on, and that might give you an indication as where the bottleneck is.


#15

i don’t think this is something that can be sped up without changing the optimization parameters for the linker. At home i got a dual Xeon@2.40GHz (4core each) 8GBram and a OCZ RevoDrive that can read 740MB/s and write 690MB at about 100,000 IOPS so i doubt it’s any of that, it just takes that long. It would be faster with a faster CPU cause it does not matter how many cores it’s one thread doing one thing. I wonder however witch optimization options can be changed to speed this up on windows+juce.


#16

I put my intermediate files (object files, etc…) on to a RAM disk for speed.


#17

well i got all my hardware to do faster builds, the revo drive is the fastest storage i found on the market, but i checked and the disk subsystem is not the issue at the time of linking it’s the cpu (in my case)