您認爲值得爲代碼質量和可維護性取捨一些性能嗎？我記得Jeff Atwood發表的一篇文章說硬件價格便宜，開發者不是。我想我想將其改爲「硬件便宜，時間不對。」性能與代碼質量對比
我注意到最近我一直在努力的MVC項目，有時候我失去了DAYS只是試圖從我的應用程序中擠出一點額外的性能，我開始認爲它不值得。我剛剛發現自己在設計ASP.NET MVC應用程序時遇到了麻煩。我喜歡IQueryable到死亡事實，它允許我追加到查詢，所以我可以得到一些流利的代碼使用它。但能夠做到這樣的事情似乎在控制器/ BLL上增加了更多的責任。
那麼你怎麼看？在網絡應用程序的情況下，你可以將一些性能換算成可維護/更清晰的代碼嗎？你是否認爲過早嘗試優化你所能做的一切？因爲我們已經看到你無法預測所有要求。
我真的不相信這是一個/或。如果你編寫乾淨而簡單的代碼，只處理所有處理的次數，你就可以得到一些性能最好的代碼。這真的很簡單。
顯而易見的答案是它取決於。如果您的應用程序足夠慢以至於很大程度上影響可用性，並且您有測量結果來證明您的優化實際上有所幫助，那麼犧牲可維護性可能是一個合理的折衷。另一方面，如果您沒有測量或應用程序速度不夠快而損害可用性，請務必閱讀易讀性，可維護性和靈活性。這只是歸結爲過早優化是所有邪惡的根源。
注：設計時間算法和架構優化不一定是件壞事，如果你知道性能這件事情影響你的應用程序，但在你的問題的情況下，你清晰地出現在談論微 -optimization，以上適用。
另外，在您的具體情況中，如果您無法判斷您的應用程序是否足夠慢以至於無法使用可用性，那麼爲時過早。如果你可以，那麼它不是。
我想這是我編輯的問題的根源。過早優化。 – 2009-02-14 22:35:41
我絕對不珍惜我自己對應用程序性能的時間在服務器端。如果我注意到我的網站在數據庫請求等方面表現不佳，那麼升級服務器硬件是另一種解決方案，可以（至少是短期的）解決我的問題，而無需查看代碼。
但是，如果應用程序是非常網絡 -inefficient，我會花很長一段時間試圖改善的部分。發送大量數據會影響我的用戶，無論我使用自己的服務器和上行鏈路 - 如果他們不喜歡性能，他們將不會回來。
但隨着其他幾個人說，這不是任何一個問題/或 - 這取決於情況很多，性能問題是多麼沉重，在應用中等等
無論是質量（意爲容易閱讀）也不是最重要的表現 - 正確性是！
託尼霍爾爵士有句名言：「我們應該忘記小效率，約97％的時間：過早優化是萬惡之源。」
報價的第一部分已經被人們遺忘了（它並不容易），因此許多沒有經驗的工程師在軟件項目的設計階段沒有考慮性能。這幾乎總是一個致命的錯誤，因爲後來設計糟糕的應用程序由於基本的設計缺陷而難以優化。同時，當性能瓶頸還不知道時，通過巧妙的技巧嘗試節省CPU週期毫無意義。
至於你的問題，我認爲一個設計合理的應用程序是爲了應付其特定的性能要求而不需要以不可維護或「不潔淨」的方式進行編碼。只有當發現這些性能瓶頸時（例如，您發現您的應用程序在其代碼的10％中花費了90％的時間），您可能需要謹慎考慮在少量代碼中使用優化技巧，以便它仍然存在可維護且易於理解。
很多Web應用程序的優點是可以使用各種緩存技術大幅提升性能。當你控制服務器環境（就像你說的那樣，硬件很便宜），你可以確保將你的Web應用程序的常用部分放在地獄之外。如果您使用抽象層，這並不能真正保留不可維護的代碼。 Facebook是Web應用程序的一個很好的例子，着名的是它利用緩存（memcached）的優勢。
在某種程度上同意這一點。開發人員的時間是昂貴的，分析和優化代碼是一個非常昂貴的方式來獲得可能沒有太多的性能增益。說到這取決於應用程序的類型和您所處的環境。
如果您正在開發一個Web應用程序，那麼您可以通過修復一些簡單的問題（主要在客戶端-側）。諸如通過連接CSS/JS文件，構建映像精靈等來減少HTTP請求......與實際分析代碼相比將帶來巨大的收益，並且對開發人員時間非常有用。
我不知道我同意'硬件比開發人員報價便宜。當然，硬件可以幫助您擴展您的應用程序，並賦予它更多性能優勢，但您最不想做的事情依賴於強健的硬件。如果您的軟件與您的硬件緊密耦合，那麼在遷移到新的數據中心，升級服務器等方面失去了很大的靈活性，而從長遠來看，如果沒有這種靈活性，成本可能會很高。假設您決定有效擴展應用程序的方式是轉向亞馬遜的EC2基礎架構。如果您的應用程序需要 32GB內存在每臺服務器上，您將發現這樣的移動可能需要重新寫入。
所有很好的答案。速度和乾淨的代碼之間的選擇是錯誤的二分法。
我還沒有看到你的工作，但我看過別人，它總是同一個故事：
「這不是足夠快，我認爲這個問題是在XXX的代碼。我想我會調整這一點，看看是否有幫助。」
你不知道的問題是存在的。
你猜測。
決不做任何事根據猜測。
（當然你絕不會那樣做，你會嗎？但大多數人做的。）
您可以剖析代碼。
我最喜歡的方法是在緩慢的時候停下來幾次，問問它在做什麼。
這通常是一個人不可能猜到的驚喜。
質量的標準定義是「符合客戶期望（要求）」。如果你已經完成了很好的需求收集，那麼你已經同意了某些性能標準。如果你的應用符合這個標準，那麼你就是在浪費你或者客戶的時間和金錢，試圖做得更好。
編寫鬆散耦合，內聚和易讀的代碼只是降低了與錯誤和需求變化相關的風險和成本。如果你準備接受「泥巴球」編碼的風險，那麼繼續。我，我喜歡賺錢。
在談論性能之前，您應該真正瞭解大O符號，您可以在有關算法或維基百科的任何書籍中查看。
Big O表示法說明了函數需要多少時間。例如。從0到100的列表有O（N）。無論O符號的數量多少都保持不變。此函數具有線性運行時間，無法以任何方式進行改進。
現在，如果你有一個從0到100的列表，並且對於列表中的每個項目，你做了另一個從0到100的列表，你得到O（N^2），這是工作的兩倍，運行時間差得多比O（N）。
在編寫必須具有良好性能的應用程序時，我們討論如何獲得用O表示法編寫的良好運行時。無論窗口是否使用< 0.1秒或大於1秒，使用相同的算法無關緊要。
這意味着，你做的秒的剃鬚可能沒有一個不同的O符號，所以你沒有以任何方式真正優化你的代碼 - 所以對你來說，在asp.net中編寫MVC我會建議你專注於編寫乾淨可讀的代碼:)
當您瞭解了O符號後，您將能夠以最少的方式知道要選擇哪些算法（如何對列表進行排序，填充它們，檢索數據）在O表示法中運行時間，並且這種知識可以使代碼快得多，而不是通過縮短代碼的秒數來寫出緊密循環所能做到的。
Makach ^^
好的設計往往犧牲改善總體方案的一些性能。例如，編寫代碼層有成本，但我們仍然這樣做，因爲它使得長期更容易地更改代碼。我們遠程使用應用程序服務器，並不是因爲它是最有效的方式，而是因爲它的規模。
我記得Code Complete 2，麥康奈爾給出了一個例子，使代碼非常難以閱讀是必要的優化。這個特殊的例子是一種加密算法。該程序被製作成一種方法來消除調用函數的開銷。所以，這確實是一個時間和地點，但我認爲這很少見。
至於解決性能問題，在大多數情況下，我發現性能問題是數據庫/ IO相關或a（內存泄漏）。正如其他人所建議的那樣，剖析是一條可行的路線，但追蹤許多錯誤仍然很棘手。
至於硬件問題，硬件放鬆了，但並沒有消除對優化代碼的需求。速度更快的硬件只能讓我們使用不太理想的語言，並且可以做出非常棒的圖形用戶界面。
這是經典的折衷表現與支持性之一。在編寫COBOL結構化代碼時（在20世紀80年代早期），我首先遇到了這種交易。很明顯，通過將所有內容分離成可重複使用的模塊，創建額外的分支和堆棧指針管理，並在早期的計算機上降低性能。答案是將函數組合在一起（並複製某些函數），以減少用於調用模塊的代碼交換和堆棧指針操作。這導致了一個支持性問題。
接下來，最近，我不得不對數據庫取消規範化，以創建可以緩存的大對象。這裏的問題是閱讀CRM系統導航期間的角色和責任訪問權限。長話短說，規範化的版本花了很長時間來處理和加載每個屏幕，所以30年來我仍然參與這個經典的折衷。
我不懷疑你不能同時擁有這兩個事實。這個問題的確是針對你認爲值得爲其他人進行一些表現交換等。對不起，我說錯了。 – 2009-02-14 22:38:57
我總是假裝我是我自己的客戶，我正在爲...設計一個應用程序...只要它工作正常，並且沒有其他人正在關注那些關心它是多麼乾淨的代碼......只要它作品 – dswatik 2009-02-14 22:45:46
Touche業務員。 – 2009-02-14 22:48:00