Atitit.提升軟體Web應用程式 app性能的方法原理 h5 js java c# php python android .net 1. 提升單例有能力的1 2. 減少工作數量2 2.1. 減少距離2 2.2. 添加索引2 2.3. Dma api2 2.4. Cdn2 2.5. Cache2 ...

Atitit.提升軟體Web應用程式 app性能的方法原理 h5 js java c# php python android .net

1. 提升單例有能力的

2. 減少工作數量

2.1. 減少距離

2.2. 添加索引

2.3. Dma api

2.4. Cdn

2.5. Cache

2.6. Pool技術

2.7. 減少HTTP請求數

2.8. ·更大的數據格式

如今的 64 位處理器是當初的 4 位處理器長期演變的結果。每次轉變都使得處理更大的數據元素速度更快，並支持處理器直接定址更大的記憶體。這些先進特性對於性能的提升和能力上的擴充是十分關鍵的，而沒有這些先進特性，今天的數據密集型應用將難以想像。

對比一下可發現，32 位處理器可直接定址高達 4 GB 的記憶體；而 64 位處理器理論上則可定址高達約 1,800 萬 TB的記憶體（實際定址容量取決於具體部署）。這是一次巨大的飛躍，很可能需要經過一段時間以後，硬體及軟體開發人員才能充分利用那些他們現在已經能夠利用的較大定址空間。

作者:: ★(attilax)>>> 綽號:老哇的爪子（全名：：Attilax Akbar Al Rapanui 阿提拉克斯阿克巴阿爾拉帕努伊）漢字名：艾龍， EMAIL:[email protected]

轉載請註明來源： http://www.cnblogs.com/attilax/

2.9. 迴圈展開

迴圈展開將兩個或更多個迴圈迭代合併到一起，以減少迴圈計數。迴圈展開雖然常常會導致代碼長度增加，但它可以減少必須執行的指令數。下麵是一個非常簡單的迴圈展開示例，它從迴圈中刪除了一個分支：

這是經典的速度優化,但許多編譯程式(如gcc -funroll-loops)能自動完成這個事,所以現在你自己來優化這個顯得效果不明顯。

不過註意:對於中間變數或結果被更改的迴圈,編譯程式往往拒絕展開,(怕擔責任唄),這時候就需要你自己來做展開工作了.

還有一點請註意,在有內部指令cache的CPU上(如MMX晶元),因為迴圈展開的代碼很大,往往cache溢出,這時展開的代碼會頻繁地在CPU 的cache和記憶體之間調來調去,又因為cache速度很高,所以此時迴圈展開反而會變慢.還有就是迴圈展開會影響矢量運算優化。

在最內層迴圈避免使用全局變數和靜態變數,除非你能確定它在迴圈周期中不會動態變化,大多數編譯器們優化變數僅有置成寄存器變數一招,而對於動態變數,它們乾脆放棄對整個表達式的優化.

2.10. 迴圈轉置

有些機器對JNZ(為0轉移

有些機器對JNZ(為0轉移)有特別的指令處理,速度非常快,如果你的迴圈對方向不敏感,可以由大向小迴圈。

舊代碼:
     for (i = 1; i <= MAX; i++)
    {
        ...
    }

新代碼:
    i = MAX+1;
    while (--i)
    {
        ...
    }

不過千萬註意,如果指針操作使用了i值,這種方法可能引起指針索引超界的嚴重錯誤(i = MAX+1;).當然你可以通過對i做加減運算來糾正,但是這樣加速的作用就沒有了除非類似於以下情況

2.11. 提高Cache命中率

·數組合併·迴圈交換·迴圈合併

·分塊

集中訪問可取入cache的塊狀矩陣，避免全行或全列的讀寫，以增強時間局部性。

2.12. 小組件替換大組件

Bootstrap 替換 amazeui

3. 並行處理

3.1. 多線程

3.2. 資料庫分區

4. 減少等候

4.1. 2、流水線（Pipeline）

　　流水線是現代RISC核心的一個重要設計，它極大地提高了性能。
　　對於一條具體的指令執行過程，通常可以分為五個部分：取指令，指令解碼，取操作數，運算（ALU），寫結果。其中前三步一般由指令控制器完成，後兩步則由運算器完成。按照傳統的方式，所有指令順序執行，那麼先是指令控制器工作，完成第一條指令的前三步，然後運算器工作，完成後兩步，在指令控制器工作，完成第二條指令的前三步，在是運算器，完成第二條指令的後兩部……很明顯，當指令控制器工作是運算器基本上在休息，而當運算器在工作時指令控制器卻在休息，造成了相當大的資源浪費。解決方法很容易想到，當指令控制器完成了第一條指令的前三步後，直接開始第二條指令的操作，運算單元也是。這樣就形成了流水線系統，這是一條2級流水線。

4.2. 亂序執行---相關

　　在一個流水線系統中，如果第二條指令需要用到第一條指令的結果，這種情況叫做相關。以上面哪個5級流水線為例，當第二條指令需要取操作數時，第一條指令的運算還沒有完成，如果這時第二條指令就去取操作數，就會得到錯誤的結果。所以，這時整條流水線不得不停頓下來，等待第一條指令的完成。這是很討厭的問題，特別是對於比較長的流水線，比如20級，這種停頓通常要損失十幾個時鐘周期。目前解決這個問題的方法是亂序執行。亂序執行的原理是在兩條相關指令中插入不相關的指令，使整條流水線順暢。比如上面的例子中，開始執行第一條指令後直接開始執行第三條指令（假設第三條指令不相關），然後才開始執行第二條指令，這樣當第二條指令需要取操作數時第一條指令剛好完成，而且第三條指令也快要完成了，整條流水線不會停頓。當然，流水線的阻塞現象還是不能完全避免的，尤其是當相關指令非常多的時候。

一般來說，當一條語句計算出來的值，後續語句不要理解使用，需要隔幾條語句（通常為4條語句）後再使用前面計算得出的值，這是因為流水線原因，當前面的值計算比較費時，後面的指令就不能執行，流水線就會被阻塞，有些編譯器可以優化，採用亂序執行方式，讓計算語句後面的指令在不等計算語句完成前接著執行，這樣就能夠保證流水線的平滑。

4.3. 分支預測

轉移
　　另一個大問題是條件轉移。在上面的例子中，如果第一條指令是一個條件轉移指令，那麼系統就會不清楚下麵應該執行那一條指令？這時就必須等第一條指令的判斷結果出來才能執行第二條指令。條件轉移所造成的流水線停頓甚至比相關還要嚴重的多。所以，現在採用分支預測技術來處理轉移問題。雖然我們的程式中充滿著分支，而且哪一條分支都是有可能的，但大多數情況下總是選擇某一分支。比如一個迴圈的末尾是一個分支，除了最後一次我們需要跳出迴圈外，其他的時候我們總是選擇繼續迴圈這條分支。根據這些原理，分支預測技術可以在沒有得到結果之前預測下一條指令是什麼，並執行它。現在的分支預測技術能夠達到90%以上的正確率，但是，一旦預測錯誤，CPU仍然不得不清理整條流水線並回到分支點。這將損失大量的時鐘周期。所以，進一步提高分支預測的準確率也是正在研究的一個課題。
　　越是長的流水線，相關和轉移兩大問題也越嚴重，所以，流水線並不是越長越好，超標量也不是越多越好，找到一個速度與效率的平衡點才是最重要的。

4.4. 靜態指令調度and 動態指令調整

4.5. 運算順序調整

通常的演算法設計和程式實現中，人們習慣在需要某數據的地方纔計算出該數據的值，緊接著使用該數據。這是很自然的思維習慣，但對於流水線則會造成麻煩。

兩個運算相繼進行，但後一個運算需要的操作數還沒有被計算出來，只有原地等待，造成了流水線的停滯。