Hardware ups and downs, part 4: RAMming speed

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.

5 thoughts on “Hardware ups and downs, part 4: RAMming speed”

  1. 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?)

  2. 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.)

  3. >
    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.

  4. 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.

Comments are closed.