2009-02-12 131 views
7

當說這段代碼需要一些優化,或者可以做一些優化時,這是什麼意思?哪種代碼需要優化?如何將優化應用於C#中的代碼?那有什麼好處?什麼是代碼優化?

回答

15

優化是一個非常廣泛的術語。總體而言,這意味着修改系統以使其某些方面更有效地工作或使用更少的資源或更強大。例如,計算機程序可能會被優化,以便其執行速度更快或使用更少的內存或磁盤存儲空間,或者在UI方面更具響應能力。

雖然「優化」與「優化」具有相同的根,但優化過程不會產生完全最優的系統:總是存在折衷,因此只有最感興趣的屬性才被優化。

請記住:

程序優化的第一條規則:不要做。程序優化的第二條規則(僅限專家!):不要這樣做。 (Michael A. Jackson

+3

+1,但我討厭傑克遜的報價。基本上它是說祈禱你已經設計了一個高性能系統,如果沒有,推遲必要的修復直到最後一刻。海事組織,一個災難的祕訣。我只是說,瞭解你的perforance要求,並據此發展。 – 2009-02-12 08:10:02

+1

我更喜歡Donald Knuth的話,「我們應該忘記小效率,大約97%的時間:不成熟的優化是萬惡之源,但我們不應該在這個關鍵的3%中放棄我們的機會。」這個關鍵的3%是這個引用的一個特別重要的部分(通常被忽略)。這是低垂的果實。有時最大的收益可以通過最小的努力來實現。您只需花費一些時間來衡量和分析以找出這些瓶頸。 – 2011-08-17 19:35:36

-3

它可能是例如,代碼中有一塊代碼被複制,可以/應該放入方法中,您可能會使用不推薦的方法/類,可能會有更簡單的方法來執行代碼正在做,可能有一些清理工作要做(例如刪除硬編碼)等等。

+0

我認爲這就是所謂的重構。這不完全是一回事。 – 2009-02-12 07:32:19

3

代碼優化使代碼運行更快。這樣做有兩種主要方法:

1)將更多的工作壓縮到更少的週期中。找出代碼在做額外的拷貝的位置,或者在緊密的循環中有一個分支。這是在小的優化。

2)使您的算法更好地擴展。您可能聽說過「大O」符號。這使得使用大量數據的算法會降低速度。

例如,如果您天真地搜索電話簿中的名稱,您將從第1頁開始,並閱讀所有名稱,直到找到您正在查找的名稱。這將需要按照電話簿中姓名的數量進行縮放。我們稱之爲O(n)。現在想想你真的如何搜索電話簿。你向中間的某個地方開放,看看你正在尋找的名字是哪一邊。這稱爲二進制搜索,並按名稱數量的對數進行縮放。我們稱之爲O(logn)。它快得多。

記住優化的第一條規則:先測量。許多人多年來一直花費在優化代碼上,而這些代碼並沒有太多運行。

5

Optimization是修改系統以使其某些方面更高效地工作或使用更少資源的過程。

你的情況主要是指2級:

設計水平

在最高級別,設計人員可以優化,使可用資源的最佳利用。這種設計的實現將受益於高效算法的良好選擇,並且這些算法的實現將從編寫高質量代碼中受益。系統的架構設計壓倒性地影響其性能。算法的選擇比任何其他設計項目都更能影響效率。然而在某些情況下,優化依賴於使用更好的算法,利用特殊情況和特殊技巧並執行復雜的權衡;因此,如果評論不充分,對於缺乏經驗的程序員來說,完全優化的程序有時候會更難理解,因此可能比未優化的版本包含更多的故障。

源代碼級

避免質量不好的編碼還可以提高性能,通過避免使用明顯放緩。然而,在那之後,一些優化是可能的,這實際上降低了可維護性;有些但不是全部都可以通過優化編譯器來執行。例如,通常需要使用更多的間接方法來簡化或改進軟件,但這種間接性會帶來成本。

1

要添加到Anton Gogolev的答案,當一段代碼需要優化時,這是因爲不符合特定的性能要求。我們制定計劃來滿足用戶的需求,對嗎?大多數程序員往往主要考慮功能需求,即程序的功能,但用戶也會有性能需求,提供什麼資源成本(網絡帶寬,CPU週期,內存,磁盤空間等)功能。優化是更改一段代碼以滿足特定性能要求的過程。恕我直言,這應該發生在設計時,但你有時會寫一段代碼,只發現它表現不佳。要優化代碼,首先必須找出哪些是您正在使用的資源。如果是CPU週期或內存,分析器可能會有所幫助。如果是網絡帶寬,這是目前很常見的網絡帶寬,則需要進行一些負載測試和通信分析。

我的建議是在編寫代碼之前始終了解您當前和未來的性能要求,並在設計階段進行優化。晚優化是昂貴的,困難的,並且經常失敗或導致難看的代碼。

1

優化主要有兩個目的:

  • 讓你的軟件使用更少的資源,例如,運行速度更快,更小,使用更少的內存,更少的硬盤空間都在運行時和存儲文檔時,網點少訪問,...

  • 通過重構來讓您的軟件更易於維護。

你並不需要,只要沒有相關的問題已經被提出來優化:這是更難以調試優化的代碼,而不是優化正確的代碼。

3

在進行代碼優化時,您需要對代碼進行度量,並嘗試使其更高效。度量通常是指稀缺資源。

下面是常見的指標

  • 執行速度(通常是:第一,涉及到說的時候腦海優化)
  • 內存消耗
  • 可執行文件的大小(在嵌入式系統中,很重要)
  • 數據庫訪問
  • 遠程服務訪問(使其不那麼健談,緩存..)
  • 簡潔,可讀性,代碼

優化後的代碼應該給予同樣的結果的可維護性。

問題是你必須做出選擇。執行速度往往伴隨着更多的內存消耗...

你也應該考慮全局優化。當您花費1000毫秒等待Web服務時,在循環中獲得10毫秒的增益完全沒用。