I've seen a bunch of sites that benchmark new hardware on gaming performance, zipping some files, encoding a movie, or whatever. Are there any that test the impact of new hardware (like SSDs, new CPUs, RAM speeds, or whatever) on compile and link speeds, either linux or windows?

It'd be really good to find out what mattered the most for compile speed and be able to focus on that, instead of just extrapolating from other benchmarks.

  • I think this belongs on SuperUser. Mar 19, 2011 at 0:06
  • 2
    @Mahmoud Hossam: Sort of a mixed topic, compilation is an intensely programmer only activity, whilst hardware benchmarks are definitely a different territory.
    – Orbling
    Mar 19, 2011 at 0:13
  • @Orbling well, he's not asking whether he should compile X or Y, he's asking if people use compiling in general to do benchmarks. Mar 19, 2011 at 8:53
  • 1
    i did some kokizzu.blogspot.co.id/2015/02/…
    – Kokizzu
    Feb 27, 2016 at 2:20
  • 1
    There's a CPU benchmark based on Linux kernel compilation times here: openbenchmarking.org/showdown/pts/build-linux-kernel
    – sjakobi
    Feb 15, 2017 at 0:42

3 Answers 3


I did that for a while - see here and here.

At the time, I was working on GTK+ and X11 hacks for a Linux cell phone distro, and every time I touched something on such a low level, it triggered rebuilding all kinds of things. One of my colleagues never did complete builds because, on the computer the company supplied with the standard compile options, it took five hours.

I had all kinds of crazy hardware sitting around at home, so I ran benchmarks on some machines while I coded on others, and you can see the results at the links.

For what we were doing on Ubuntu, once I maxed out CPU utilization - which you can do really easily with the -j argument to make - the bottleneck seemed to be the disk.

But then the company had big layoffs, so I was out the door, and didn't finish scoping that all out. I had a lot of data and interpretation I didn't post on that blog, too.

  • Shame to build it up with two detailed posts and them stop. Do you still have all that data? In any case, it would be very interesting to see some blog posts/answers with some conclusions of what you found.
    – Hugo
    Jul 17, 2011 at 8:16
  • @Hugo: No, I'm afraid not - the raw data is long gone. But basically what I came up with is that for the systems (1-8 CPU cores) and source code (the Linux kernel) I was testing, the fastest build times were when the -j option was at 1.5x the number of cores, with -j=2 being best for one core. Below that, the systems were CPU bound, and above that, they were I/O bound. It's an interesting question - maybe I should take it up again someday.
    – Bob Murphy
    Jul 17, 2011 at 21:08

Tom's Hardware used to, but it looks like they stopped doing it back in 2008: http://www.tomshardware.com/charts/desktop-cpu-charts-q3-2008/benchmarks,31.html. None of the newer CPU charts include the Linux Kernel compiling test.


First on my wishlist is a Solid State Drive. It won't have a huge impact on compile time, but opening applications becomes drastically faster (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

The biggest factor for compile time is going to be CPU. You're pretty safe using this for the benchmark http://www.cpubenchmark.net/.

  • 1
    Then again a lot depends on your build chain. If your build chain only uses a single thread for compilation on a multi-CPU, a multi-core or even a multi-threaded CPU, you are wasting an opportunity for massive gains. A plain CPU benchmark wont show that, and a compilation benchmark would only be good for a given toolchain.
    – asoundmove
    Mar 19, 2011 at 2:03
  • 2
    Actually, I found by experiment that once you do parallel compilation, it's your disk that's the bottleneck. Within reason, you're better off with a slower CPU and a faster disk than vice versa.
    – Bob Murphy
    Jun 17, 2011 at 1:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.