?2016-2026 Matools All rights reserved,
粵ICP備17059708號(hào)
一、通常的性能問題類型
讓我們一起看看那些公共的性能問題,看看他們是或者不是.我們將了解到為什么我們常常在開發(fā)期間會(huì)錯(cuò)過這些問題.
我們也會(huì)看看當(dāng)我們考慮性能時(shí)語言的選擇、延遲、帶寬、計(jì)算等因素.
二、語言的考慮
人們經(jīng)常關(guān)注所使用的編程語言的速度。然而，這經(jīng)常沒有抓住要點(diǎn)。這是一個(gè)非常簡單的觀點(diǎn)，掩蓋了技術(shù)選擇的細(xì)微差別,
用任何語言編寫速度慢的軟件都很容易。由于當(dāng)今計(jì)算機(jī)的處理速度非常強(qiáng)大，所以解釋性能相對較慢的語言通常足夠快，而開發(fā)中性能的提高是值得的.
要理解所涉及的論點(diǎn)和權(quán)衡是很重要的，即使在讀完這本書之后您決定使用C#和.NET.
編寫速度最快的軟件的方法是深入了解底層硬件并用匯編語言編寫。（甚至機(jī)器代碼）。但開發(fā)、調(diào)試和測試都很復(fù)雜，這需要專家形
知識(shí)。我們現(xiàn)在很少這樣做，除了非常小的應(yīng)用程序（如虛擬現(xiàn)實(shí)游戲、科學(xué)數(shù)據(jù)處理，有時(shí)還有嵌入式設(shè)備），但通常只用于軟件的一小部分.
?C＃在速度和靈活性之間提供了良好的平衡，使其適用于各種各樣的應(yīng)用程序，尤其是服務(wù)器端Web應(yīng)用程序
三、性能問題的類別
1.延遲
內(nèi)存延遲
網(wǎng)絡(luò)延遲
磁盤IO延遲
繁瑣的交互/握手
2.帶寬
過載的負(fù)荷
未優(yōu)化的數(shù)據(jù)
壓縮的平衡
3.計(jì)算問題
工作于過于大量的數(shù)據(jù)
計(jì)算非必須的結(jié)果
暴力的算法
4.響應(yīng)
可離線處理的同步操作
緩存及處理作廢的數(shù)據(jù)
在為平臺(tái)編寫軟件時(shí)，通常會(huì)受到兩種資源的限制。即:計(jì)算處理速度和訪問遠(yuǎn)程（到處理器）資源。處理速度如今很少是一個(gè)限制因素，這可以用于與其他資源進(jìn)行交易,
例如，壓縮一些數(shù)據(jù)以減少網(wǎng)絡(luò)傳輸時(shí)間。
訪問遠(yuǎn)程資源（如主內(nèi)存，磁盤和網(wǎng)絡(luò)）將產(chǎn)生各種時(shí)間成本。了解處理速度不是受單個(gè)值影響，而是多個(gè)參數(shù)影響非常重要。這些參數(shù)中帶寬和延遲是最重要的,
延遲是操作開始之前的滯后時(shí)間，而帶寬是數(shù)據(jù)在操作開始后轉(zhuǎn)移的速率。提交一個(gè)硬盤驅(qū)動(dòng)事件的帶寬是非常高的，也是具有非常高的延遲的。這會(huì)使來回發(fā)送大量文本文件變得非常慢，但是或許，發(fā)送大量
3D視頻是一個(gè)不錯(cuò)的選擇（取決于Weissman
得分了）。
移動(dòng)電話數(shù)據(jù)連接可能更適合文本文件。 雖然這是一個(gè)人為的例子，但是同樣的問題通常適用于計(jì)算堆棧的每一層，其時(shí)間差的數(shù)量級相似。
問題在于差異太快無法察覺，我們需要使用工具和科學(xué)來看待它們。
解決性能問題的秘訣是對該技術(shù)有更深入的了解,并知道在較低級別會(huì)發(fā)生什么。 您應(yīng)該了解框架在網(wǎng)絡(luò)級別上的說明。
掌握這些命令如何在底層硬件上運(yùn)行以及它們?nèi)绾问艿讲渴鸬降幕A(chǔ)架構(gòu)的影響也很重要。
四、什么時(shí)候性能是重要的
性能并不總是很重要。知道什么時(shí)候是重要的,什么時(shí)候不重要,
是非常必要的技能。一般的經(jīng)驗(yàn)法則是，如果用戶需要花事件來等待事情發(fā)生，那么就應(yīng)該讓性能良好。如果可以異步執(zhí)行對用戶沒有影響,就可以按照異步地方式執(zhí)行,如:隊(duì)列,
或者其他非UI線程.
某些情況下,程序被設(shè)計(jì)為看起來緩慢,主要的原因是為了系統(tǒng)安全,例如一些解密算法.
五、為什么常常沒有發(fā)現(xiàn)性能問題
在開發(fā)中沒有注意到性能問題的主要原因之一是一些問題在開發(fā)系統(tǒng)上是不可感知的。在延遲增加之前可能不會(huì)出現(xiàn)問題。這可能是因?yàn)榇罅康臄?shù)據(jù)被加載到系統(tǒng)中并且檢索特定的記錄需要更長的時(shí)間。這也可能是因?yàn)槊總€(gè)系統(tǒng)被部署到單獨(dú)的服務(wù)器上，從而增加了網(wǎng)絡(luò)等待時(shí)間。
另外當(dāng)數(shù)據(jù)量沒有上來,或者請求量沒有上來,這些問題都是難以發(fā)現(xiàn)的.所以提前的壓測是很有必要的.
當(dāng)您從一開始就考慮性能時(shí)，解決問題的成本更低、速度更快。對于軟件開發(fā)中的大多數(shù)問題來說，這都是正確的。越早抓到BUG
，越好。發(fā)現(xiàn)錯(cuò)誤的最糟糕的時(shí)間是一旦部署，然后由用戶報(bào)告。與功能性BUG
相比，性能問題有點(diǎn)不同，因?yàn)樗鼈兺ǔＶ辉谝?guī)模上顯示出來，除非您去尋找它們，否則在實(shí)際部署之前您不會(huì)注意到它們。您可以編寫集成測試和負(fù)載測試，以對照具體的量化目標(biāo)檢查性能，我們將在本書后面討論這些目標(biāo)。
??
熱門工具 換一換