為了更好的優化程式效能，我們必須找到效能瓶頸點，也就是熱點函式。在linux系統中可以使用vtune和gprof兩種方式來統計函式佔總執行時間的比例。此次先記錄一下使用gprof的方法。
gprof是gnu工具之一，預設情況下linux系統當中都帶有這個工具。它在編譯的時候在每個函式的出入口加入了profiling的**，執行時統計程式在使用者態的 執行資訊，可以得到每個函式的呼叫次數，執行時間，呼叫關係等資訊，簡單易懂。適合於查詢使用者級程式的效能瓶頸，對於很多時間都在核心態執行的程式，gprof不適合。
除錯環境：
1、centos7、fortran程式、mpi+openmp、使用8程序單執行緒結構
使用makefile檔案編譯，其中編譯選項：mpifort -mp -cpp -o3 -g -pg -c ***.f90
執行語句：mpirun -np 8 ./***
2、centos7、c程式、序列
編譯語句：gcc -o gprof-test -pg gprof-test.c
執行語句：./gprof-test
示例均顯示第二個c程式的結果，第乙個fortran的結果類似
證明linux下c程式和fortran程式、序列還是多程序都可以使用gprof測試程式
使用gprof時要新增-pg選項來編譯檔案，如果要得到帶注釋的原始碼清單，則需要增加 -g 選項。單句執行：mpifort -mp -cpp -o3 -g -pg -c ***.f90，我的編譯是直接make。這個時候當前資料夾下是沒有gmon.out檔案的，結果如下圖所示。
==>> 生成可執行檔案***
==>> 生成可執行檔案gprof-test
注：如果是程式包中含有多個.c或.f90檔案，要保證每乙個檔案編譯時均有-pg選項，沒有-pg選項的檔案中涉及到的函式不會被統計進去，不會影響程式執行。
執行完之後在當前資料夾下會生成乙個gmon.out檔案，gprof所有是統計資訊均儲存在gmon.out檔案中，不管是.c還是.f90生成的均是gmon.out
使用gprof來分析 gmon.out檔案，需要把它和產生它的應用程式關聯起來
結果截圖如下圖所示，執行了乙個簡單的序列程式，只有乙個gprof-test.c檔案。上述編譯執行測試的多程序fortran程式也有相應結果，和此類似。
注：程式正常執行結束後，會產生gmon.out. 但在某些情況下，因為程式不能正常退出，gmon.out是不能生成的
網路資源
gprof 使用者手冊
使用 gnu profiler 來提高**執行速度
參考部落格：
oracle 效能調優之等待事件統計
等待事件統計 等待事件是通過會話增量累計的用力表示會話在它能夠繼續執行以前等待乙個事件完成。當乙個會話處理乙個使用者請求必須等待時，資料庫記錄通過使用一系列預先定義的等待事件來等待。這是事件按照等待級別分組，就像使用者i o和網路。等待事件資料 揭露可能影響資料庫效能的症狀。就像鎖啊，快取或者i o...
ABAP 報表程式OpenSQL效能調優
臨上線了，需求還在改，報表也得改，需求滿足了，程式效能又不滿足了，淨折騰啊 可客戶是付錢的上帝，所以程式要調優要改進，不然，要錢不給！sap 系統是經典的三層架構，分為db,應用伺服器，展示層三層 abap程式執行在應用伺服器層，訪問的資料儲存在db，而我們要做的就是把資料從db中取出來，然後送到展...
C 程式常見的效能調優方式
冗餘的變數拷貝 相對c而言，寫c 經常一不小心就會引入一些臨時變數，比如函式實參 函式返回值。在臨時變數之外，也會有其他一些情況會帶來一些冗餘的變數拷貝。之前針對冗餘的變數拷貝問題寫過一些帖子，詳情這裡。多重過濾 很多服務都會過濾的部分結果的需求，比如遊戲交談中過濾需要過濾掉敏感詞。假設現在有兩個過...