首頁猿問優(yōu)化C#/.NET程序的技巧

優(yōu)化C#/.NET程序的技巧

C# .NET

有只小跳蛙 2019-07-03 16:01:56

優(yōu)化C#/.NET程序的技巧現(xiàn)在看來，優(yōu)化是一門丟失的藝術(shù)。難道不是有一段時間，所有的程序員都在壓縮他們的代碼的每一盎司的效率嗎？在雪中行走五英里時經(jīng)常這樣做？本著找回失去的藝術(shù)的精神，對于簡單的(或者可能是復(fù)雜的)更改來優(yōu)化C#/.NET代碼，您知道哪些技巧？因?yàn)檫@是一件非常廣泛的事情，這取決于一個人想要完成什么，這將有助于為你的技巧提供背景。例如：將多個字符串連接在一起時，請使用StringBuilder相反。請參閱底部的鏈接，以了解對此的注意事項(xiàng)。使用string.Compare比較兩個字符串而不是執(zhí)行類似的操作string1.ToLower() == string2.ToLower()到目前為止，普遍的共識似乎是衡量的關(guān)鍵。這種情況忽略了要點(diǎn)：測量并不能告訴你哪里出了問題，或者如果你遇到瓶頸該怎么辦。我曾經(jīng)遇到過字符串連接瓶頸，不知道該怎么辦，所以這些技巧是有用的。我甚至發(fā)布這篇文章的目的是要為常見的瓶頸提供一個位置，以及在遇到這些瓶頸之前如何避免這些瓶頸。任何人都不一定要盲目地遵循即插即用代碼，而是要更多地理解，至少在某種程度上，應(yīng)該考慮性能，還有一些常見的缺陷需要注意。不過，我可以看出，知道小費(fèi)為什么有用，以及應(yīng)該在哪里應(yīng)用，也可能是有用的。為StringBuilder提示我找到了我很久以前做過的幫助在喬恩·斯基特的網(wǎng)站上.

查看完整描述

3 回答

森欄

TA貢獻(xiàn)1810條經(jīng)驗(yàn) 獲得超5個贊

現(xiàn)在看來，優(yōu)化是一門丟失的藝術(shù)。

曾經(jīng)有一天，顯微鏡的制造被當(dāng)作一門藝術(shù)來實(shí)踐。人們對光學(xué)原理知之甚少。零件沒有標(biāo)準(zhǔn)化。管子、齒輪和鏡片必須由高技能的工人手工制作。

如今，顯微鏡是作為一門工程學(xué)科而產(chǎn)生的。物理的基本原理是非常清楚的，現(xiàn)成的零件是廣泛可用的，顯微鏡制造工程師可以作出明智的選擇，如何優(yōu)化他們的儀器來完成它設(shè)計(jì)的任務(wù)。

表現(xiàn)分析是一種“失傳的藝術(shù)”，是一件非常好的事情。那門藝術(shù)是被實(shí)踐的作為一種藝術(shù)..應(yīng)該根據(jù)實(shí)際情況進(jìn)行優(yōu)化：工程問題可通過仔細(xì)應(yīng)用固體工程原理來解決。

多年來，我多次被問及我的“技巧和技巧”清單，人們可以用這些方法來優(yōu)化VBScript/jscript/他們的活動服務(wù)器頁面/他們的VB/他們的C#代碼。我總是抗拒這個。強(qiáng)調(diào)“技巧和技巧”是完全錯誤的方式來接近性能。這種方式導(dǎo)致的代碼很難理解，很難推理，很難維護(hù)，這通常不會比相應(yīng)的直接代碼更快。

處理性能的正確方法是將其作為一個工程問題來處理，就像任何其他問題一樣：

設(shè)定有意義的、可衡量的、以客戶為中心的目標(biāo).
構(gòu)建測試套件，在現(xiàn)實(shí)但可控制和可重復(fù)的條件下對照這些目標(biāo)測試您的性能。
如果這些套件顯示你沒有達(dá)到你的目標(biāo)，那么就使用一些工具，比如分析器來找出原因。
優(yōu)化剖析器所確定的最糟糕的子系統(tǒng)。保持對每個更改的分析，以便清楚地了解每個更改對性能的影響。
重復(fù)三件事中的一件，直到有一件事情發(fā)生：(1)你達(dá)到了目標(biāo)，然后把軟件發(fā)送出去；(2)你把目標(biāo)向下修正到你能達(dá)到的目標(biāo)；或者(3)你的項(xiàng)目被取消了，因?yàn)槟銦o法達(dá)到你的目標(biāo)。

這和你解決任何其他工程問題是一樣的，比如為這個特性添加一個功能設(shè)定的客戶目標(biāo)，跟蹤在實(shí)現(xiàn)方面的進(jìn)展，通過仔細(xì)的調(diào)試分析修復(fù)問題，一直迭代直到你發(fā)布或失敗。性能是一個特點(diǎn)。

對復(fù)雜的現(xiàn)代系統(tǒng)的性能分析需要紀(jì)律和專注于堅(jiān)實(shí)的工程原理，而不是一個小范圍適用于瑣碎或不現(xiàn)實(shí)情況的技巧包。我從來沒有通過應(yīng)用技巧和技巧來解決現(xiàn)實(shí)世界的性能問題。

反對回復(fù) 2019-07-03

拉風(fēng)的咖菲貓

TA貢獻(xiàn)1995條經(jīng)驗(yàn) 獲得超2個贊

找個好的側(cè)寫員。

即使沒有一個好的分析器，也不要費(fèi)心去優(yōu)化C#(真的，任何代碼)。實(shí)際上，手頭有一個采樣和一個跟蹤分析器非常有幫助。

如果沒有一個好的分析器，您可能會創(chuàng)建錯誤的優(yōu)化，最重要的是，優(yōu)化那些從一開始就不是性能問題的例程。

輪廓的前三個步驟應(yīng)該是：(1)度量，(2)度量，然后(3)度量.

反對回復(fù) 2019-07-03

慕尼黑5688855

TA貢獻(xiàn)1848條經(jīng)驗(yàn) 獲得超2個贊

優(yōu)化準(zhǔn)則：

除非你需要，否則不要這樣做。
如果用新硬件代替開發(fā)人員來解決問題更便宜，就不要這么做
不要這樣做，除非您可以測量生產(chǎn)等效環(huán)境中的變化。
除非你知道如何使用CPU，否則不要這么做。
和
內(nèi)存分析器
如果這樣做會使您的代碼不可讀或無法維護(hù)，請不要這樣做。

由于處理器的速度越來越快，大多數(shù)應(yīng)用程序的主要瓶頸不是CPU，而是帶寬：片外內(nèi)存帶寬、磁盤帶寬和網(wǎng)絡(luò)帶寬。

從遠(yuǎn)端開始：使用YSlow來了解為什么您的網(wǎng)站對于最終用戶來說是緩慢的，然后向后移動并修復(fù)您的數(shù)據(jù)庫訪問不太寬(列)和不太深(行)。

在非常罕見的情況下，為優(yōu)化CPU使用做任何事情都是值得的，請注意不要對內(nèi)存使用產(chǎn)生負(fù)面影響：我看到了“優(yōu)化”，開發(fā)人員試圖使用內(nèi)存來緩存結(jié)果以節(jié)省CPU周期。凈效果是減少可用內(nèi)存來緩存頁面和數(shù)據(jù)庫結(jié)果，這使得應(yīng)用程序運(yùn)行速度慢得多！(見關(guān)于測量的規(guī)則。)

我也看到過這樣的情況：一種“愚蠢”的非優(yōu)化算法擊敗了“聰明”優(yōu)化算法。千萬不要低估編譯器編寫人員和芯片設(shè)計(jì)者在將“低效”循環(huán)代碼轉(zhuǎn)化為超級高效代碼方面的作用，這些代碼完全可以在芯片上的內(nèi)存中通過流水線方式運(yùn)行。你的“聰明”的基于樹的算法有一個未包裝的內(nèi)循環(huán)反算，你認(rèn)為它是“有效的”，它可以被擊敗，僅僅是因?yàn)樗趫?zhí)行過程中沒有停留在芯片上的內(nèi)存中。(見關(guān)于測量的規(guī)則。)

反對回復(fù) 2019-07-03