I finished my tests of building Mozilla Firefox with and without a RAMDisk, and the results were a little surprising. Read on in the extended entry for details.
| Build configuration | Debug | Debug | Debug | Debug | Opt | Opt | Opt | Opt | ||||
| RAMdisk mozilla-build | N | N | Y | Y | N | N | Y | Y | ||||
| RAMdisk sourcedir/objdir | N | Y | N | Y | N | Y | N | Y | ||||
| Time of build | 92m 19.192s | 84m 8.784s | 87m 54.002s | 82m 55.015s | 50m 32.067s | 46m 59.342s | 51m 16.507s | 47m 83.553 | ||||
| Time of build | 89m 6.443s | 83m 12.905s | 89m 41.610s | 83m 4.294s | 52m 8.315s | 47m 5.456s | 50m 55.042s | 47m 1.541s | ||||
| Time of build | 88m 27.776s | 85m 4.024s | 86m 38.466s | 84m 4.759s | 51m 11.907s | 47m 10.682s | 50m 19.646s | 47m 2.664s |
The test conditions were:
- 4GB RAM disk from QSoft initialized at all times
- Only the console was open, and as many tray icons that could be closed were closed
- Norton Antivirus was not disabled
- I cleared the objdir each time, ran configure, and timed the build part of the process
- I locked the desktop each time I started a build, and visited it only when I was certain it was done
- I made no attempt to load VC8 into a RAMDisk.
- I used the same mozconfig files for each set of builds.
Running the MozillaBuild environment from a RAMDisk made no appreciable difference. In this, I was disappointed, as I figured MozillaBuild may be able to benefit from a RAMDisk location. I guess not.
Placing the sourcedir and objdir in a RAMDisk cut about five minutes off the build time for a debug build, and a little less for an optimized build. The five-minute difference was surprising to me because it was so small. I expected a much larger difference.
The build system still had to refer to the hard drive for every time we went to the C++ compiler and linker. This could be a big factor, because I’d wager Visual Studio took better than 80% of the time in the build. I’m just not that daring.
Overall, if you’re looking for a way to reduce build time because you build all the time (tinderbox, anyone?), you can get a slight tweak (about 5.5 percent) putting the source tree and objdir in a RAM disk. Other than that, don’t spend the $250.00 on the extra RAM.
I would like to see how I could load VC8 onto the RAMDisk though, and compile from that. If it’s possible. For the moment, though, I’m done with this experiment.
Why did you expect anything different?
Compiling is heavily limited by processing power, disc I/O is no factor at all unless you have *really* slow drives.
Often accessed executables should be cached in RAM by the OS anyway, so I don’t think putting VS in a ramdisc will help either.
(From Alex: Well, if that’s the case, considering the specs on this box, there should have been *no* difference between any of the builds. But I did notice a 5% savings in the objdir case. What’s the explanation there?)
Disabling Norton would have made the biggest improvement.
see the numbers here: http://www.codinghorror.com/blog/archives/000803.html
Was this a clean build? I would expect the biggest wins here for a dep build, honestly, especially if you’re using ccache and actually have the cache on ramdisk too.
In other words, the less the compile is CPU-bound, the more a ramdisk will help.
(From Alex: Yes, these were clean builds, with all objdirs deleted before each run began. I don’t know anything about ccache.)
>
First accesses. Without ramdisk every object that’s accessed has to be loaded from disk at least once. On second access they’re ideally already cached in RAM anyway, as Bernd said.
Thanks for trying this! I was looking to speed up our project build (I mean like 5x, not 5% ;)) and you’ve saved me the effort of trying this. I guess there is no quick-fit solution… faster CPUs or fast build servers might be the solution. Or patience. Yup, that should work.