指針越大，對齊邊界越大，數據越稀疏，等效代碼也越大。我們就這樣將雞肋的信息融入高速緩存行、代碼或是數據，并因此降低了緩沖區命中率。一切，是的，一切都會受到影響。因為處理器緩存并沒有增加。系統中其他程序也會受到影響，即使運行的代碼沒有發生變化。反正我們并不需要額外的內存。除了減速，我們一無所獲。
他繼續說道，
大多數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位并減少內存的消耗，將會對應用程序和操作系統所構成的整體產生更大的影響。
查看英文原文：Rico Mariani on Why Visual Studio Isn’t 64-bit
京公網安備 11010502049343號