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

研究 malloc

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

#!/bin/sh

exportCURL_MEMDEBUG=$HOME/tmp/curlmem.log

./src/curl http://localhost

./tests/memanalyze.pl-v $HOME/tmp/curlmem.log

對于 curl 7.53.1，這大約有 115 次內存分配。這算多還是少？

內存日志非常基礎。為了讓你有所了解，這是一個示例片段：

MEM getinfo.c:70free((nil))

MEM getinfo.c:73free((nil))

MEM url.c:294free((nil))

MEM url.c:297strdup(0x559e7150d616)(24)=0x559e73760f98

MEM url.c:294free((nil))

MEM url.c:297strdup(0x559e7150d62e)(22)=0x559e73760fc8

MEM multi.c:302calloc(1,480)=0x559e73760ff8

MEM hash.c:75malloc(224)=0x559e737611f8

MEM hash.c:75malloc(29152)=0x559e737a2bc8

MEM hash.c:75malloc(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：

http://www.example.com/

http://localhost/512M

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

首先，我使用 7.53.1 來測試上面的例子，并使用 memanalyze 腳本檢查：

Mallocs:33901

Reallocs:5

Callocs:24

Strdups:31

Wcsdups:0

Frees:33956

Allocations:33961

Maximumallocated:160385

好了，所以它總共使用了 160KB 的內存，分配操作次數超過 33900 次。而它下載超過 512 兆字節的數據，所以它每 15KB 數據有一次 malloc。是好是壞？

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

Mallocs:69

Reallocs:5

Callocs:24

Strdups:31

Wcsdups:0

Frees:124

Allocations:129

Maximumallocated: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，并運行這個命令：

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 的下載，給出時間。我運行了三次新代碼和舊代碼，其運行“中值”如下：

舊代碼：

real0m36.705s

user0m20.176s

sys0m16.072s

新代碼：

real0m29.032s

user0m12.196s

sys0m12.820s

承載這個 80GB 文件的服務器是標準的 Apache 2.4.25，文件存儲在 SSD 上，我的機器的 CPU 是 i7 3770K 3.50GHz 。

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

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

總結

以上是生活随笔為你收集整理的linux malloc命令,减少 curl 中内存分配操作（malloc）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。