July 5, 2008

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.

Posted by WeirdAl at July 5, 2008 2:21 PM
Comments

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

Posted by: Bernd at July 5, 2008 3:52 PM

Disabling Norton would have made the biggest improvement.

see the numbers here: http://www.codinghorror.com/blog/archives/000803.html

Posted by: Fowl at July 5, 2008 6:24 PM

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

Posted by: Boris at July 5, 2008 9:57 PM

>

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.

Posted by: laszlo at July 6, 2008 1:30 PM
Post a comment









Remember personal info?