5 ms·
This doesn't appear to cache compiled "scripts", which to me makes it kind of useless. It's nice not to leave binaries laying around but I'd expect things to be
by 0942v8653 12y ago
This doesn't appear to cache compiled "scripts", which to me makes it kind of useless. It's nice not to leave binaries laying around but I'd expect things to be saved (otherwise it's pretty slow).
- maffydub 12y agoIt 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