LiteSetup多線程優化方案

LiteSetup 輕量級安裝程序框架  項目中：

主要是2方面能夠多線程優化處理：UI和核心代碼，核心代碼的壓縮多線程處理

1.最開始UI和核心代碼在一個線程，致使可能假死現象，

解決方案：給核心代碼單獨開一個線程。

結果：解決假死問題。僞代碼以下

...
void Compress()
{
std::thread t(...
{
...
});
t.detach();
}
...

 

2.因爲核心代碼跑在一個線程，致使只能利用一個CPU邏輯核心，壓縮速度不快

測試數據：打包450MB 左右的ra2，可見 壓縮佔用時間20s ，io讀寫  分別爲7s  和 0.2s

HDD數據

SSD數據

可見性能瓶頸在壓縮處理

優化方案：

1.壓縮部分開啓多線程支持，在讀取文件片斷後即刻開啓一個線程 來壓縮 完成後添加到緩存隊列，管理線程。

2.勢必內存會瘋長，因此限制當前文件緩存大小，例如： 若是緩存大小 大於100MB就馬上寫入。

3.若是壓縮線程數爲0，意味着壓縮完畢，就馬上把緩存的剩下部分，寫入文件。處理後續事件。

整個過程以後壓縮是多線程，文件寫入是某個壓縮線程完成後 執行的，文件讀取是在覈心線程完成。最後利用輪詢是否平衡的

思想斷定是否壓縮完畢。

測試數據：（整個壓縮過程（ 文件讀取，數據壓縮，文件寫入））

優化前：   

整個打包過程 25s

優化後：

整個打包過程9s 

結果：加入多線程優化後，效率提高特別大，雖然線程開銷致使等效時間（單獨一個線程壓縮時間，和多個線程每一個線程壓縮時間之和）多了，36.912-23.461=13秒，可是總效率提高3倍。

部分核心代碼：

進一步優化：雖然初步方案獲得了很好的效果，可是線程效率比 不高，能夠進一步優化。

1. 經過線程池來管理建立的線程，提升單個線程效率

2.dump文件（寫入文件）的時候 添加多線程機制，原方案是在某個壓縮線程中寫入，可能會致使其餘壓縮完成但未寫入緩存的線程掛起

3.調整不一樣的文件塊大小 ，可適當加大FileReader的文件塊大小 減小線程切換代價，用內存換取時間。

4.dump文件限制可適當加大，加快總體速度。