Here is an interesting quote from the guys that build Twitter:

Disclaimer: I am completely ignorant about Ruby and Rails, should maybe I should just shut up.

One thing that I have noticed is that all those "neat" stuff can be very costly in its default implementation, but it doesn't have to be. Let us take a look at dasBlog's macros for an instance, shall we? The initial implementation was very easy to use (and probably to implement), but was very slow due to heavy use of uncached reflection.

One way to get over it is to drop the notions of macros entirely, and do it all by hand. That would make it much harder to use them, of course. Another way would be to optimize the macros themselves. Recent version of dasBlog has done just that, by using cached reflection, and the numbers I have seen quotes talks about 100% improvement in performance, with no difference for the user. From experiance, this optimization can be as hard as the actual functionality, but the tradeoffs across the board are more than worth it.

Assuming that we reached the next scaling point, where cached reflection is still too slow, what do we do then? Beyond cache reflection, we have runtime code generation, which is more complex still, but offers the speed of the native platform. Here we get to thinking about tradeoffs, it may be that the complexity would cost more than the convenience is worth, but most often, the complexity is localized to a narrow set of functionality, and it enable quite a bit of cost saving.

Again, I have no idea about Rails and the kind of problems that he is talking about, but if I were facing this issue, I would probably try to see if I can JIT the Ruby code into native code, and run that. There is quite a bit that can be done if the scenario is focused enough that you can make assumption about the way it is used (remove edge cases, basically).