背景

使用C++開發了一個Redis數據導入工具
從oracle中將所有表數據導入到redis中；
不是單純的數據導入，每條oracle中的原有記錄，需要經過業務邏輯處理，
并添加索引（redis集合）；
工具完成后，性能是個瓶頸；

優化效果

使用了2個樣本數據測試：
樣本數據a表8763 條記錄；
b表940279 條記錄；

優化前，a表耗時11.417s；
優化后，a表耗時1.883s；

用到的工具

gprof, pstrace,time

使用time工具查看每次執行的耗時，分別包含用戶時間和系統時間；
使用pstrace打印實時運行，查詢進程主要的系統調用，發現耗時點；
使用gprof統計程序的耗時匯總，集中精力優化最耗時的地方；

使用簡介：

1.對g++的所有編輯和連接選項都必須要加上-pg（第一天由于沒有在連接處加上-pg選項，導致無法出統計報告）；
2.執行完程序后，本目錄會產生gmon.out文件；
3.gprof redistool gmou.out > report,生成可讀文件report，打開report集中優化最耗時的函數；

優化過程

優化前11.417s：

文件內存映射

系統調用時間過長，主要是文件讀寫，初步考慮是讀取文件時，調用api次數過于頻繁；
讀取樣本采用的是文件fgets一行行的讀取，采用文件內存映射mmap后，可直接使用指針操作整個文件內存快；

日志開關提前

改進了文件讀寫后，發現優化效果比較有限（提高了2s左右）；fgets是C的文件讀取庫函數，相比系統read()，是帶了緩沖區了，應該不會太慢（網上有人測試，文件內存映射相比fgets()能快上一個數量級，感覺場景應該比較特殊）；

之后通過pstrace工具發現log.dat打開次數過多；原來是調試日志的開關寫到了后面，導致 調試日志都是會打開日志文件open("log.dat")；
將日志開關提前；改進后，3.53s

vector空間預先分配

后續通過gprof分析，某個函數的vector內存分配次數多，并有不少復制次數：
改進以下這行代碼：

vector <string> vSegment;
使用靜態vector變量，并預先分配內存：

優化后，提升至2.286s

同樣，另外一個類中的成員vector也使用預先分配空間（在構造函數中)：

m_vtPipecmd.reserve(256);
優化后，提升至2.166s;

函數改寫 && 內聯

繼續執行程序，發現SqToolStrSplitByCh()函數消耗過大，改寫整個函數邏輯，并將改寫后的函數內聯：
優化后，提升至1.937s

去除調試符和優化監測符號

最后，去掉debug和pg調試符號后，最終效果為1.883s；

滿足生產要求

以上最后幾步看似毫秒級的提升，擴大到全表數據后，效果就很明顯了；
優化后，生產上a表為152w，導入耗時大約326s（~6分鐘）；
b表數據420w，導入耗時大約1103s（~18分鐘）

以上所述就是本文的全部內容了，希望大家能夠喜歡。