用gprof分析時的神秘函數_L_lock_154

Question

在分析我的代碼時，gprof輸出以下內容：

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 30.69     10.55    10.55                             _L_lock_154
 16.58     16.25     5.70 1126059616     0.00     0.00  double_cmp
 14.25     21.15     4.90    13737     0.36     0.36  bsdi
 10.01     24.59     3.44                             memcpy

（僅參加第一行）

排名第一是我不認識的功能，不幸的是，谷歌也沒有。

可能是什么-有人知道嗎？ 由於它占用了我大部分時間，我很想知道。

使用mikes建議進行DIY分析，我經常看到此堆棧回溯：

Program received signal SIGINT, Interrupt.
0xb7fff424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fff424 in __kernel_vsyscall ()
#1  0x080ada62 in __write_nocancel ()
#2  0x080859c1 in _IO_new_file_write ()
#3  0x08084b64 in new_do_write ()
#4  0x080861ed in _IO_new_do_write ()
#5  0x080869c5 in _IO_new_file_overflow ()
#6  0x08085f3e in _IO_new_file_xsputn ()
#7  0x080c4d54 in vfprintf ()
#8  0x080b071c in __fprintf_chk ()
#9  0x0805ec36 in fprint_track_hum ()
#10 0x0805efe1 in fprint_hash_tracks ()
#11 0x08049c33 in main (argc=22, argv=0xbfffeac4) at harness.c:537

盡管我看不到對_L_lock_154的調用，但我開始認為這可能是與file / stdio.h相關的打印內容-寫入文件指針或類似內容的鎖定。 因此，我將嘗試禁用所有打印和重新配置文件，看看神秘功能是否消失。

更新1

不，這仍然是一個謎，禁用了所有輸出到file / stdout的功能，但是有條理的_L_lock_154仍然占用了我10％的時間。 可能與從文件讀取有關，但是如果沒有一些輸入，我將無法運行我的工具。

我真的很驚訝google在此方面留下了空白-非常罕見。

更新＃2

只是在調用圖中而不是在平面模式下運行了gprof-它為_L_lock_154吐出了它：

granularity: each sample hit covers 4 byte(s) for 0.03% of 36.86 seconds

index % time    self  children    called     name
                                                 <spontaneous>
[1]     49.6   11.82    6.45                 _L_lock_154 [1]
                5.84    0.00 1198163721/1198163721     double_cmp [8]
                0.52    0.00 125628587/125628587     fptype_cmp [24]
                0.04    0.00 13096233/13096233     grp_cmp_by_density_descending [52]
                0.04    0.00 3464916/3464916     pdw_ptr_cmp_by_amp [53]
                0.01    0.00   73812/73812       pdw_ptr_cmp_by_idx [89]
                0.00    0.00   71682/9288620     int_cmp [44]
                0.00    0.00  636314/842100      pri_ptr_cmp_by_second_pdw_idx [123]
                0.00    0.00  277089/407783      pri_ptr_cmp_by_first_pdw_idx [124]
                0.00    0.00   76178/76178       window_cmp_by_emitter_id [128]
                0.00    0.00   10147/10147       pri_ptr_cmp_by_first_pdw_toa [137]
-----------------------------------------------

我確定這是想告訴我一些事情，但是我不確定如何解釋它？ 我所有的cmp類型函數都與stdlib中的qsort一起使用-如果_L_lock_154是所有這些調用的父級，是否暗示它是qsort的別名？

Answer 1

好的， gprof在CPU時間上采樣，而在掛鍾時間上隨機暫停采樣。 因此，當gprof表示例程花費30％的時間時，這意味着CPU時間，這可能不到牆上時鍾時間的1％。 換句話說，您受I / O約束。 因此，即使您可以將時間設為0，也永遠不會看到差異。 （這就是為什么我鄙視“ CPU配置文件”的原因-它使經驗不足的程序員將注意力集中在無關緊要的事情上。）

如果不清楚，您的程序可能會進行1微秒的實際計算，其中很大一部分是進入和退出例程的I / O堆棧。 一旦到達I / O堆棧的底部，它可能要等待99微秒才能出來，並使用CPU還要等待1微秒。 gprof僅告訴您如何使用1％的時間，就好像這很重要。

為了在隨機暫停中獲得與gprof相當的結果，您必須丟棄任何包含__kernel_vsyscall樣本。 因此，在找到一個實際使用CPU時間的樣本之前，您可能必須進行100次采樣。 這項工作很多，但是如果您做到了，我希望您會在大約30％的非I / O樣本上看到Lock例程。

請記住，編寫gprof時，是由UC Berkeley的工作人員進行的，UC Berkeley是在學術環境中開發版本的unix 。 它有一個內置的假設-所有I / O都是必需的 I / O。 在實際的用戶級軟件中，通常並非如此。 此外，I / O並非非CPU時間，而是不同的 CPU。 有一個運行該磁盤，端口或隨您所需的I / O控制器芯片。