函式開銷困惑

在現代的開發作業中，相信絕大部分的同學手頭的專案都不是從第零行代碼開始搭建的，各個語言都有自己流行的代碼框架，如PHP的有Laravel、CodeIgniter、ThinkPHP等等，大家都是在自己的框架的基礎上添加自己的業務代碼邏輯，開啟開發作業，還記得我們團隊有位開發同學當時問過我一個問題，我們用xx框架這么重，一個用戶請求過來即使什么也不干，都已經進行了那么多次的函式呼叫了，適合用來做介面開發嗎？
我當時給她的回答是，沒問題放心吧，函式呼叫的開銷很小的，不必擔心，但回答完她的問題之后，我回頭一想，我只知道函式呼叫的開銷很小，但是具體是多大，我心里并吃不準，這就在我心里又種下了草，后來終于抽空進行了一次實踐研究，把草拔掉了，

C語言測驗

測驗代碼很簡單，這就是一個for回圈的函式呼叫，代碼如下：

#include <stdio.h>  
int func(int p){   
	return 1;
}  
int main()  
{  
	int i;  
	for(i=0; i<100000000; i++){  
		func(2);  
	}  
	return 0;  
}

函式呼叫耗時測驗

我們用time命令來進行耗時測驗

# gcc main.c -o main  
# time ./main  
real    0m0.335s  
user    0m0.334s  
sys     0m0.000s  

#perf stat ./main  
......  
1,100,989,673 instructions              #    1.37  insns per cycle  
......  

不過上面的實驗中有個多余的開銷，那就是for回圈，我們單獨計算一下這個for的開銷，把func()呼叫那行注釋掉，單獨保留1億次的for回圈，再重新編譯執行一遍，結果是

time ./main  
real    0m0.293s  
user    0m0.292s  
sys     0m0.000s  

perf stat ./main  
......  
301,252,997 instructions   #    0.43  insns per cycle
......  

通過上面兩步測驗的資料，(0.335-0.293)/100000000=0.4ns，我們可以得出結論1：每個c函式呼叫耗時大約是0.4ns左右，

函式呼叫CPU指令數分析

我們用perf命令可以統計到程式運行的底層CPU指令個數，1億次的函式呼叫統計結果如下：

# perf stat ./main  
......  
1,100,989,673 instructions              #    1.37  insns per cycle  
......  

去掉for回圈后，單獨1億次的for回圈統計如下：

# perf stat ./main  
......  
301,252,997 instructions   #    0.43  insns per cycle
......  

通過這兩個資料，(1,100,989,673-301,252,997)/100000000=8個，所以我們得出結論2：每個c函式需要的CPU指令數是8個！，

函式呼叫CPU指令剖析

如果有同學和我一樣好奇結論2中的每個c函式的CPU指令到底干了些啥，請和我一起來，否則請開啟3倍速快進，還是上述的實驗代碼，我們通過gdb的disassemble來查看一下其內部匯編執行程序,編譯之，

gcc -g main.c -o main

再用gdb命令除錯：

gdb ./main
start
disassemble
mov    $0x2,%edi

看到函式到了main函式處，并列印出了main函式的匯編代碼

......
=> 0x0000000000400486 <+4>:	mov    $0x2,%edi
   0x000000000040048b <+9>:	callq  0x400474 <func>
......

這是進入函式呼叫的兩個CPU指令，每個指令大概含義如下：

• 指令1：mov $0x2,%edi是為了呼叫函式做準備，把引數放到暫存器中，
• 指令2：callq表示cpu開始執行func函式的代碼段，

接下來讓我們進入到func函式內部看一下：

break func
run

這時函式停在了func函式的入口處, 繼續使用gdb的disassemble命令查看匯編指令：

(gdb) disassemble
Dump of assembler code for function func:
   0x0000000000400474 <+0>:	push   %rbp
   0x0000000000400475 <+1>:	mov    %rsp,%rbp
   0x0000000000400478 <+4>:	mov    %edi,-0x4(%rbp)
=> 0x000000000040047b <+7>:	mov    $0x1,%eax
   0x0000000000400480 <+12>:	leaveq 
   0x0000000000400481 <+13>:	retq   
End of assembler dump.

這6個指令是對應在函式內部執行，以及函式回傳的操作，加上前面2個，這樣在結論2中的每個函式8個CPU指令就都水落石出了，

• 指令3：push %rbp bp暫存器的值壓入呼叫堆疊，即將main函式堆疊幀的堆疊底地址入堆疊（對應一次壓堆疊操作，記憶體IO）
• 指令4：mov %rsp,%rbp被調函式的堆疊幀堆疊底地址放入bp暫存器，建立func函式的堆疊幀（一次暫存器操作），
• 指令5：mov %edi,-0x4(%rbp)是從暫存器的地址-4的記憶體中取出，即獲取輸入引數（記憶體IO）
• 指令6：mov $0x1,%eax對應return 0，即是將回傳引數寫到暫存器中（記憶體讀IO）

再接下來的兩個執行令是進行呼叫堆疊的退堆疊，以便于回傳到main函式繼續執行，是指令3和指令4的逆操作，

• 指令7：leave q等價于mov %rbp, %rsp，暫存器操作
• 指令8：retq 等價于pop %rbp（記憶體IO）

總結：8次CPU指令中大部分都是暫存器的操作，即使有“記憶體IO”，也是在堆疊上進行，而堆疊操作密集，符合區域性原理，早就被L1快取住了，其實都是L1的IO，所以耗時很低，前面實驗結果表明1次函式呼叫的開銷是0.4ns， 耗時竟然小于1次真正物理記憶體IO的耗時（40ns左右），

指令并行

不知道大家有沒有人注意到，前面兩次perf stat的結果中分別有如下兩個提示

• 0.43 insns per cycle
• 1.37 insns per cycle
  這是說現代的CPU可以通過流水線的方式對CPU指令進行并行處理，當指令符合并行規則的時候，每個CPU周期內執行的指令數可能會大于1，這就是CPU指令并行的功勞， 所以增加函式呼叫后耗時并沒有增加太多，除了函式呼叫本身開銷不大的原因以外，還有一個原因就是函式呼叫讓CPU的流水線并行技術得以施展，每秒處理的CPU指令數更多了，

PHP語言測驗

很多同學又會問題，你用的是C語言進行測驗，性能當然高了，

• “我用的可是PHP，這可是腳本語言”
• “我用的可是Java，中間可還有一層虛擬機”
• “我用的可是...”

好了，不抬杠，我們繼續試一試不就完了么，就用php來繼續實驗一把，

<?php  
function func(){  
	return true;  
}  
for($i=0;$i<10000000;$i++){  
	func();  
}  

實驗結果：

• php7： 1000W次耗時0.667s，減去0.140s的for回圈耗時，平均每次函式呼叫耗時52ns
• php53：1000W次耗時2.1s，減去0.5s的for回圈耗時，平均每次耗時160ns

結論

php的函式呼叫確實比c的要慢很多，從不到1ns升高到了50ns左右，因為php又用c虛擬了一層指令集，這層指令集還需要變成CPU的指令集后才可以真正運行，但是要知道的是ns這個時間單位太小了，假如你用的框架特別變態，一個用戶請求來了直接就搞了1000次的函式呼叫，那么消耗在函式呼叫上的時間會是50ns*1000=50us，這和代碼框架化后給團隊專案帶來的便利性來對比的話，這點時間開銷，我覺得仍然是可以忽略的，

開發內功修煉之CPU篇專輯：

• 1.你以為你的多核CPU都是真核嗎？多核“假象”
• 2.聽說你只知記憶體，而不知快取？CPU表示很傷心！
• 3.TLB快取是個神馬鬼，如何查看TLB miss？
• 4.行程/執行緒切換究竟需要多少開銷？
• 5.協程究竟比執行緒牛在什么地方？
• 6.軟中斷會吃掉你多少CPU？
• 7.一次系統呼叫開銷到底有多大？
• 8.一次簡單的php請求redis會有哪些開銷？
• 9.函式呼叫太多了會有性能問題嗎？

我的公眾號是「開發內功修煉」，在這里我不是單純介紹技術理論，也不只介紹實踐經驗，而是把理論與實踐結合起來，用實踐加深對理論的理解、用理論提高你的技術實踐能力，歡迎你來關注我的公眾號，也請分享給你的好友~~~

標籤：其他

上一篇：一次簡單的redis網路請求會有哪些CPU開銷？

下一篇：shell編程