This is a pretty myopic view of performance and 32-bit code. - You really only get 3GB of RAM - Actually, you get less than that, because of DLLs that get loa

This is a pretty myopic view of performance and 32-bit code. - You really only get 3GB of RAM - Actually, you get less than that, because of DLLs that get loaded into that space. - Actually actually, fragmentation becomes a problem, and making very good use of the remaining memory gets awkward pretty quickly. 3GB is pretty crowded, especially when you're talking about (say) a game with tens of GB of footprint. You need to page stuff into that footprint, and be clever about the memory pressure not affecting the user experience. On the server side of things, we regularly run processes with > 8GB footprints, including things like solr (at 32 to 160GB). Breaking this stuff up would involve a lot more disk and network chatter, as well as bugs involving OOM conditions, reducing global performance and reliability. So while VS may be fine with 32-bit code+data (I am not convinced), real-world applications definitely need more. I'm guessing that making a 64-bit VS is hard for legacy reasons, and that the 32-bit space is actually holding the VS team back (and possibly plugin makers as well).