Myles has explained way in which you might be able to tune your set-up.
On the question of where Moodle 2.0 is at right now, it is feature-complete, and relatively bug-free. However, it has only just been released, and there is a lot of new code there that has not yet be been exposed to real production loads very much yet.
It can be very hard to find the performance bottlenecks during development. You really need a few brave early-adopters to find the worse problems for you As a fairly silly example, in some code I wrote recently for the OU, it worked fine on my development machine. When were were testing it on a copy of our live database, one particular operation was taking 20 minutes, which was crazy. I went back and looked a the code, and it was basically a sequence of five database operations. I then spent a lot of time trying to optimise one the the queries that was obviously the slow one, without luck. Then I actually measured the time the each query was taking, and it turned out that it was one of the queries that looked quite simple that was taking 20 minutes. Then I was able to tweak that query, and once I had done that it took 0.1s.
So, what I am saying is that in all the Moodle 2.0 code, despite the fact that it is designed to work with reasonable performance, there will be some strange bits that need to be tuned up, once we see how the behave at realistic loads. Mostly, when we find those places, doing the tuning up will be relatively easy. And that sort of activity is actively going on now. There is quite a good thread about profiling Moodle 2.0 elsewhere in this forum.
On the other hand, Moodle 2.0 does a lot more stuff than Moodle 1.9 did. I think it is inevitable that even after all the new code has been well tuned, it will be a little slower than 1.9 on the same hardware.