我有一個通常報告的應用程式（time命令報告）：
real 1.59
user 1.42
sys 4.73
但是當我加載共享庫並運行它時，時間會變得相當長（time命令報告）：
real 28.51
user 106.22
sys 5.23
雖然由於我的共享庫的工作，預計運行速度會出現一定程度的增長（在 CentOS 和 Ubuntu 上報告為 2 到 4 倍，這符合預期），但上述在 Fedora 24 上報告的時間太長了。
我嘗試使用perf報告：
255352.948615 task-clock:u (msec) # 3.895 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
18,127 page-faults:u # 0.071 K/sec
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
# 5.23 stalled cycles per insn (50.00%)
28,361,633,658 branches:u # 111.068 M/sec (50.01%)
777,249,031 branch-misses:u # 2.74% of all branches (50.01%)
65.564158710 seconds time elapsed
這似乎表明 CPU 有大量時間處於空閒狀態。但我試圖找到程式碼中發生這種情況的位置（我可以訪問我的應用程式和相關共享庫的整個原始程式碼）。我還看到perf report哪個報告了函數/系統呼叫所花費的時間的百分比。但我對更精細的層級感興趣，即這些函數中的哪一行，以便我能夠理解原因。
我很高興提供任何具體的建議並不容易，因為我沒有提供有關我的應用程式/共享庫的太多資訊。我只是在尋找建議/工具/想法來找出 CPU 大部分時間花在程式碼中的位置（或空閒的位置）。
它是帶有 glibc 2.23 的 Fedora 24 Linux/x86_64（我的應用程式和共用程式庫都是用 gcc 6.1.1 和 glibc 2.23 編譯的）。
答案1
這似乎表明 CPU 有大量時間處於空閒狀態。
是的。即 87% 的時間。但這並不意味著處理器不處理其他任務和進程。
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
優化程式以更好地利用 CPU 和記憶體存取它是複雜的任務，沒有任何程式碼，不可能更詳細地回答您。