Someday I hope it finally gets ported to x64 so that it can use more than a tiny fraction of the RAM in my desktop, instead of page thrashing all the time.
I'm Cyrus, a developer on the C#/VB IDE team.
One of the areas we invested a lot in (and will continue working on) is moving a lot of our analysis and processing work out-of-process. It turns out this is a much effective way to get improved performance while taking advantage of the available RAM in the system.
There are several reasons why this is, and why it's a better solution for performance than just moving to 64bits. For one, moving to 64bits substantially increases the memory requirements to the system. For the C#/VB compiler/IDEs, it can easily double the amount of ram necessary, which can be a substantial burden on many systems. For another, when you are in a single process, you massively increase the pressure on the GC, which can lead to exacerbated GC-pauses (which are one of the single worst contributors to the IDE feeling slow or sluggish).
By moving out of proc, we can actually use less ram, have far less chance of hitting 32bit limits, and greatly improve perceived and actual latency of operations (as GCs can happen in one process without affecting the other).
We, and other teams have been using this approach with great success, and we expect to continue moving more in this direction with future updates and releases. For example, I'm doing work right now to get our indices for 'Navigate To', 'Find all References' and 'Add using' to be computed and queried outside of the main VS process. The results have been hugely successful, with the features actually running better than before, VS being even more responsive, and no excess memory usage (like we would get with 64bit).
There has been significant investigations of 64bit, and the actual empirical results of those investigations have driven our decisions. Thanks!