Comments: Hardware ups and downs, part 4: RAMming speed

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

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.

Posted by Pranav at July 7, 2009 8:17 AM
Post a comment









Remember personal info?