A rainbow table is "just" a compact representation of a table of precomputed hash values. During the construction of the rainbow table, many possible inputs are tried and hashed. Each input which has been encountered during table construction will be successfully attacked with that table, and none other. The hash evaluation concentrates most of the table building cost.
So, basically, the cost of building a rainbow table which can invert N passwords is roughly equivalent to the cost of trying those N passwords through the hash function -- the point of the rainbow table being that you build it once and then can use it to break several passwords. (To be precise, due to chain collisions during table construction, the cost is in fact closer to 1.7*N, but let's ignore that for the moment.)
I have once made some experiences with SHA-1. A simple password hash with SHA-1 has the cost of processing a single "block" (SHA-1, like MD5, processes data by 64-byte blocks), which needs about 900 32-bit logical-or-arithmetic operations. An optimized implementation on an Intel Core2 x86 processor can do that in about 500 clock cycles. However, password attacks (whether directly or for rainbow table construction, it does not matter) are a highly parallel job, so one could use the SSE2 instructions which offer 128-bit registers, and where a single opcode can perform four 32-bit operations simultaneously. SSE2 has less kinds of operations available (in particular, it does not offer rotations, only shifts), so the operation count rises to about 1200; but, under some conditions, the SSE2 unit will execute several opcodes simultaneously. So we end up with 800 clock cycles, for four SHA-1 instances in parallel. Bottom-line: my PC is an Intel Core2 Q6600, with four cores running at 2.4 GHz. Each core can run my SSE2 implementation, resulting in roughly 48 millions hashed passwords per second.
I also have a not-too-small Nvidia graphics card, and the GPU can run arbitrary code through CUDA. This is a 9800 GTX+, with 128 cores running at 1.84 GHz. Each core may execute one 32-bit operation per cycle (there is a high latency, but, thanks to the high parallelization, this one-instruction-per-cycle throughput can be maintained). The cores do not know about rotations, so each code will use 1200 clock cycles per hashed password. The total performance is 160 millions hashed passwords per second.
My PC and graphics card are from early 2009 and are not top-of-line. One can find nowadays, for a few hundred dollars, a GPU which will hash passwords about three times faster than my 9800 GTX+. So let's assume that an attacker with a common PC (which costs less than 1000$) can hash half a billion passwords per second.
At that speed, all passwords with 8 alphanumeric characters (uppercase and lowercase letters, and digits) are gone through in about 5 days. With a 1000$ PC. If you use MD5, things are about 30% faster (MD5 uses a bit less operations than SHA-1). Good password hashing schemes do not use a simple hash invocation, though: they use iterated hashing with, say, 2000 nested hash invocations: this multiplies cost for the attacker by the same 2000 factor (so it turns the "5 days" into about 28 years, literally "ages" as you put it).
