《LINUX實操：減少 curl 中內存分配操作（malloc）》要點：
本文介紹了LINUX實操：減少 curl 中內存分配操作（malloc），希望對您有用。如果有疑問，可以聯系我們。

本日我在 libcurl 內部又做了一個小改動,使其做更少的 malloc.這一次,泛型鏈表函數被轉換成更少的 malloc (這才是鏈表函數應有的方式,真的).

?

研究 malloc

幾周前我開始研究內存分派.這很容易,因為多年前我們 curl 中就已經有內存調試和日志記錄系統了.使用 curl 的調試版本,并在我的構建目錄中運行此腳本：

對于 curl 7.53.1,這年夜約有 115 次內存分配.這算多還是少?

內存日志異常基礎.為了讓你有所了解,這是一個示例片段：

1. MEM getinfo.c:70 free((nil))
2. MEM getinfo.c:73 free((nil))
3. MEM url.c:294 free((nil))
4. MEM url.c:297 strdup(0x559e7150d616)(24)=0x559e73760f98
5. MEM url.c:294 free((nil))
6. MEM url.c:297 strdup(0x559e7150d62e)(22)=0x559e73760fc8
7. MEM multi.c:302 calloc(1,480)=0x559e73760ff8
8. MEM hash.c:75 malloc(224)=0x559e737611f8
9. MEM hash.c:75 malloc(29152)=0x559e737a2bc8
10. MEM hash.c:75 malloc(3104)=0x559e737a9dc8

?

檢查日志

然后,我對日志進行了更深入的研究,我意識到在相同的代碼行做了許多小內存分配.我們顯然有一些相當愚蠢的代碼模式,我們分配一個結構體,然后將該結構添加到鏈表或哈希,然后該代碼隨后再添加另一個小結構體,如此這般,而且經常在循環中執行.(我在這里說的是我們,不是為了責怪某個人,當然大部分的責任是我本身……)

這兩種分配操作將總是成對地出現,并被同時釋放.我決定辦理這些問題.做非常小的(小于 32 字節)的分配也是浪費的,因為非常多的數據將被用于(在 malloc 系統內)跟蹤那個微小的內存區域.更不用說堆碎片了.

因此,將該哈希和鏈表代碼修復為不使用 malloc 是快速且簡單的辦法,對于最簡單的 “curl http://localhost” 傳輸,它可以消除 20％ 以上的 malloc.

此時,我根據大小對所有的內存分配操作進行排序,并檢查所有最小的分配操作.一個突出的部門是在 curl_multi_wait() 中,它是一個典型的在 curl 傳輸主循環中被反復調用的函數.對于大多數典型情況,我將其轉換為使用堆棧.在大量重復的調用函數中避免 malloc 是一件好事.

?

重新計數

現在,如上面的腳本所示,同樣的 curl localhost 命令從 curl 7.53.1 的 115 次分配操作下降到 80 個分配操作,而沒有犧牲任何器械.輕松地有 26％ 的改善.一點也不差!

由于我修改了 curl_multi_wait(),我也想看看它實際上是如何改進一些稍微更高級一些的傳輸.我使用了 multi-double.c 示例代碼,添加了初始化內存記錄的調用,讓它使用 curl_multi_wait(),而且并行下載了這兩個 URL：

1. http://www.example.com/
2. http://localhost/512M

第二個文件是 512 兆字節的零,第一個文件是一個 600 字節的公共 html 頁面.這是 count-malloc.c 代碼.

首先,我使用 7.53.1 來測試上面的例子,并使用 memanalyze 腳本反省：

1. Mallocs:33901
2. Reallocs:5
3. Callocs:24
4. Strdups:31
5. Wcsdups:0
6. Frees:33956
7. Allocations:33961
8. Maximum allocated:160385

好了,所以它總共使用了 160KB 的內存,分配操作次數跨越 33900 次.而它下載跨越 512 兆字節的數據,所以它每 15KB 數據有一次 malloc.是好是壞?

回到 git master,現在是 7.54.1-DEV 的版本 - 因為我們不太確定當我們發布下一個版本時會變成哪個版本號.它可能是 7.54.1 或 7.55.0,它還尚未確定.我離題了,我再次運行相同修改的 multi-double.c 示例,再次對內存日志運行 memanalyze,申報來了：

1. Mallocs:69
2. Reallocs:5
3. Callocs:24
4. Strdups:31
5. Wcsdups:0
6. Frees:124
7. Allocations:129
8. Maximum allocated:153247

我不敢置信地反復看了兩遍.產生什么了嗎?為了仔細檢查,我最好再運行一次.無論我運行多少次,結果還是一樣的.

?

33961 vs 129

在典型的傳輸中 curl_multi_wait() 被調用了很多次,而且在傳輸過程中至少要正常進行一次內存分配操作,因此刪除那個單一的微小分配操作對計數器有非常大的影響.正常的傳輸也會做一些??數據移入或移出鏈表和散列操作,但是它們現在也大都是無 malloc 的.簡單地說：剩余的分配操作不會在傳輸循環中執行,所以它們的重要性不大.

以前的 curl 是當前示例分派操作數量的 263 倍.換句話說：新的是舊的分派操作數量的 0.37％ .

另外還有一點好處,新的內存分派量更少,總共減少了 7KB(4.3％).

?

malloc 重要嗎?

在幾個 G 內存的時代里,在傳輸中有幾個 malloc 真的對付普通人有顯著的區別嗎?對 512MB 數據進行的 33832 個額外的 malloc 有什么影響?

為了衡量這些變化的影響,我決定比擬 localhost 的 HTTP 傳輸,看看是否可以看到任何速度差異.localhost 對于這個測試是很好的,因為沒有網絡速度限制,更快的 curl 下載也越快.服務器端也會相同的快/慢,因為我將使用相同的測試集進行這兩個測試.

我雷同方式構建了 curl 7.53.1 和 curl 7.54.1-DEV,并運行這個命令：

1. curl http://localhost/80GB -o /dev/null

下載的 80GB 的數據會盡可能快地寫到空裝備中.

我獲得的確切數字可能不是很有用,因為它將取決于機器中的 CPU、使用的 HTTP 服務器、構建 curl 時的優化級別等,然則相對數字仍然應該是高度相關的.新代碼對決舊代碼!

7.54.1-DEV 反復地表示出更快 30％!我的早期版本是 2200MB/秒增加到當前版本的超過 2900 MB/秒.

這里的要點當然不是說它很容易在我的機器上使用單一內核以超過 20GB/秒的速度來進行 HTTP 傳輸,因為實際上很少有用戶可以通過 curl 做到這樣快速的傳輸.關鍵在于 curl 現在每個字節的傳輸使用更少的 CPU,這將使更多的 CPU 轉移到系統的其余部分來執行任何必要做的事情.或者如果設備是便攜式設備,那么可以省電.

關于 malloc 的本錢：512MB 測試中,我使用舊代碼發生了 33832 次或更多的分配.舊代碼以大約 2200MB/秒的速率進行 HTTP 傳輸.這等于每秒 145827 次 malloc - 現在它們被消除了!600 MB/秒的改進意味著每秒鐘 curl 中每個減少的 malloc 操作能額外換來多傳輸 4300 字節.

?

去掉這些 malloc 難嗎?

一點也不難,非常簡單.然而,有趣的是,在這個舊項目中,仍然有這樣的改進空間.我有這個想法已經好幾年了,我很高興我終于花點時間來實現.感謝我們的測試套件,我可以有相當大的信心做這個“激烈的”內部變化,而不會引入太可怕的回歸問題.由于我們的 API 很好地暗藏了內部,所以這種變化可以完全不改變任何舊的或新的應用程序……

(是的,我還沒在版本中發布該變更,所以這還有風險,我有點懊悔我的“這很容易”的聲明……)

?

注意數字

curl 的 git 倉庫從 7.53.1 到本日已經有 213 個提交.即使我沒有別的想法,可能還會有一次或多次的提交,而不僅僅是內存分配對性能的影響.

?

還有嗎?

還有其他類似的環境么?

也許.我們不會做很多性能測量或比較,所以誰知道呢,我們也許會做更多的愚蠢事情,我們可以罷手并做得更好.有一個事情是我一直想做,但是從來沒有做,就是添加所使用的內存/malloc 和 curl 執行速度的每日“監視” ,以便更好地跟蹤我們在這些方面不知不覺的回歸問題.

?

補遺,4/23

(關于我在 hacker news、Reddit 和其它處所讀到的關于這篇文章的評論)

有些人讓我再次運行那個 80GB 的下載,給出光陰.我運行了三次新代碼和舊代碼,其運行“中值”如下：

舊代碼：

1. real 0m36.705s
2. user 0m20.176s
3. sys 0m16.072s

新代碼：

1. real 0m29.032s
2. user 0m12.196s
3. sys 0m12.820s

承載這個 80GB 文件的服務器是尺度的 Apache 2.4.25,文件存儲在 SSD 上,我的機器的 CPU 是 i7 3770K 3.50GHz .

有些人也提到 alloca() 作為該補丁之一也是個辦理方案,但是 alloca() 移植性不夠,只能作為一個孤立的辦理方案,這意味著如果我們要使用它的話,需要寫一堆丑陋的 #ifdef.

---

via: https://daniel.haxx.se/blog/2017/04/22/fewer-mallocs-in-curl/

作者：DANIEL STENBERG 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

本文永遠更新鏈接地址：

《LINUX實操：減少 curl 中內存分配操作（malloc）》是否對您有啟發，歡迎查看更多與《LINUX實操：減少 curl 中內存分配操作（malloc）》相關教程，學精學透。維易PHP學院為您提供精彩教程。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/7038.html