指针越大，对齐边界越大，数据越稀疏，等效代码也越大。我们就这样将鸡肋的信息融入高速缓存行、代码或是数据，并因此降低了缓冲区命中率。一切，是的，一切都会受到影响。因为处理器缓存并没有增加。系统中其他程序也会受到影响，即使运行的代码没有发生变化。反正我们并不需要额外的内存。除了减速，我们一无所获。
他继续说道，
大多数Visual Stduio并不需要，也无法受益于4G以上的内存。即使有程序包真的需要这么大的内存，也可以用自己的64位进程建立，并且能够无缝集成到VS中无需为其余的部分付费。这在VS 2008中就已经可能了，也许更早。硬把所有的VS拖进64位的世界中，而无视它们的挣扎喊叫，并没有什么太大的意义。
这并不是说无法改善Visual Studio。但Rico Mariani认为，解决方案应当是如何减少VS使用的内存，而非给它更多。
现在，如果我们有某个程序包需要>4G数据，并且还有一个数据访问模型要求以超级常用的接口随时对这些数据进行访问，这种情况下诸如SendMessage这样的函数是无法完成工作的，此时我认为重新考虑存储模型会获得巨大的收益。
VS的空间中有大量的罪犯。我最喜欢投诉语言服务，它在我的整体解决方案中臭名昭著，会加载大量数据，而仅仅提供智能感知中的一小部分功能。但这好像自从2010年后就没有改变过。我常告诫VS组织的人们去考虑解决方案中如果有10k个项目（显示存在的）或50k份文件（也是真实存在的）时，系统应该如何应对。对我来说，将数据全部加载到内存中的方案不太妥当。但如果我们真的、不开玩笑的、有不能节约利用的存储空间，还一定要将数据常驻内存，那么还是将数据从进程中分离开来，放入一个64位的程序包中比较好。
再回到更多寄存器的问题，Rico补充道。
事实也证明了，额外的寄存器对于VS这种交互式应用没什么帮助，比如它不会有大量频繁的计算密集型循环。并且当命中L1时，载荷出栈的性能如此之好，可与寄存器媲美——除了指令编码的长度更糟一些。但其实64位指令编码的长度也好不到哪里去……
所以，没错，见仁见智【你可能不会这么想】，主要是和对计算引擎的显著提升相比，更多的寄存器对于大型应用的作用微乎其微。
这一立场在16位应用程序切换为32位时饱受批评。但在90年代中后期，开发者普遍到处倡导这一转变有益。“既然这样，为什么我们无法从64位的切换中获取同样的收益呢？”，这个问题经常被问到。在后续的一篇标题为64位的Visual Studio——“超级64”位参数的文章中，他解释了区别。
很明显，在有大容量硬盘和可交换内存的前提下，我们编写的任何32位寻址的程序都能够创建为16位的方式（特别是疯狂x86段的问题）。但是这么做能够得到优秀的代码么？能够体验到非凡的工程成本么？我们是在硬件的斗争上耗费大量的时间还是做各有意义的事情？在这种情况下，人们自然想到了非常酷的方式，十分经济地解决了某些问题，因为他们有了内存压力和经济动机这么做。这些是伟大的发明。但在某些方面也是一种疯狂。这种为完成任务而不得不编写的16位代码就只有丑陋而已。
这里，我的假设就不成立了。这些情况下，它不是相同的代码了。16位代码迟钝、丑陋[哔！]以可怕的方式在内存受限的环境中运行，而32位代码则优美简洁，在卓越的算法下，能够直接完成它需要做的工作。因此，相同的代码编码后体积越大运行越慢的现象其实是无关紧要的。它并不是相同的代码！并且众所周知，卓越的算法即便使用更多的内存，也要优于低劣的算法——即使它们更节约内存或代码大小。
这一课适用于我们编写的绝大多数应用程序。如果当某人正在编写计算引擎或者只能历经磨难手动交换内存，切换到64位可能有益。但是大多数情况下，保留32位并减少内存的消耗，将会对应用程序和操作系统所构成的整体产生更大的影响。
本文转自d1net（转载）
