At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use.

The author acknowledges that this can happen:

> So, you’re now out of address space. There are two ways you could try to address this.

> a) Think carefully about your data representation and encode it in a more compact fashion

> b) Allow the program to just use more memory

> I’m the performance guy so of course I’m going to recommend that first option.

As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit-fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around.

In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.