It would probably be quicker if it cached, but don't underestimate the speed of gcc... A year or so ago, as part of my work on Project Clearwater (http://www.p

It would probably be quicker if it cached, but don't underestimate the speed of gcc... A year or so ago, as part of my work on Project Clearwater (http://www.projectclearwater.org/ http://www.projectclearwater.org/), I was using a Ruby tool to retrieve statistics from a server, plumbing them into Cacti (http://www.cacti.net/ http://www.cacti.net/) and graphing the results. Cacti likes to restart statistics-gathering processes every time it wants new statistics (once a minute in my system), so this meant starting the Ruby interpreter every minute. Project Clearwater is built to be scalable, so I turned up a few hundred nodes (EC2 makes this easy), at which point Cacti couldn't keep up - it took the best part of a second per Ruby process invocation, and since I was polling every minute, there just wasn't enough time to get through all the nodes. I rewrote the Ruby tool in C++, at which point it ran in less than 0.1s, which was fast enough for what I needed. Amusingly (at least to me), it actually _compiled_ (under GCC) and ran in less time than it took for the Ruby interpreter to start. (This is not intended to be a comparison of the merits of C++ and Ruby. It's quite possible the Ruby code could have been optimized and really I was solving the wrong problem - I probably should have been making the statistics-gathering process long-lived. The point of the above is just that GCC is actually very quick for relatively small programs.) Matt