函式開銷困惑

在現代的開發工作中，相信絕大部分的同學手頭的專案都不是從第零行程式碼開始搭建的。各個語言都有自己流行的程式碼框架，如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.函式呼叫太多了會有效能問題嗎？

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