優化curl的記憶體分配操作

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

幾週前我開始研究記憶體分配。這很容易，因為多年前我們 curl 就已經有記憶體調試和日誌記錄系統了。使用 curl 的偵錯版本，並在我的建置目錄中執行此腳本：

#!/bin/sh
export CURL_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:70 free((nil))
MEM getinfo.c:73 free((nil))
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d616) (24) = 0x559e73760f98
MEM url.c:294 free((nil))
MEM url.c:297 strdup(0x559e7150d62e) (22) = 0x559e73760fc8
MEM multi.c:302 calloc(1,480) = 0x559e73760ff8
MEM hash.c:75 malloc(224) = 0x559e737611f8
MEM hash.c:75 malloc(29152) = 0x559e737a2bc8
MEM hash.c:75 malloc(3104) = 0x559e737a9dc8

然後，我對日誌進行了更深入的研究，我意識到在相同的程式碼行做了許多小記憶體分配。我們顯然有一些相當愚蠢的程式碼模式，我們分配一個結構體，然後將該結構添加到鍊錶或哈希，然後該程式碼隨後再添加另一個小結構體，如此這般，而且經常在循環中執行。 （我在這裡說的是我們，不是為了責怪某個人，當然大部分的責任是我自己…）

這兩種分配操作將總是成對地出現，並同時釋放。我決定解決這些問題。做非常小的（小於 32 位元組）的分配也是浪費的，因為非常多的資料將被用於（在 malloc 系統內）追蹤那個微小的記憶體區域。更不用說堆碎片了。

因此，將該雜湊和鍊錶程式碼修復為不使用 malloc 是快速且簡單的方法，對於最簡單的 “curl http://localhost” 傳輸，它可以消除 20％ 以上的 malloc。

此時，我根據大小對所有的記憶體分配操作進行排序，並檢查所有最小的分配操作。一個突出的部分是在curl_multi_wait() 中，它是一個典型的在 curl 傳輸主循環中被反覆呼叫的函數。對於大多數典型情況，我將其轉換為使用堆疊[2]。在大量重複的呼叫函數中避免 malloc 是一件好事。

現在，如上面的腳本所示，同樣的 curl localhost 指令從 curl 7.53.1 的 115 次分配操作下降到 80 個分配操作，而沒有犧牲任何東西。輕鬆地有 26％ 的改善。一點也不差！

由於我修改了 curl_multi_wait()，我也想看看它實際上是如何改進一些稍微更高級一些的傳輸。我使用了multi-double.c[3] 範例程式碼，添加了初始化記憶體記錄的調用，讓它使用curl_multi_wait()，並且並行下載了這兩個URL：

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

第二個檔案是 512 兆位元組的零，第一個檔案是一個 600 位元組的公共 html 頁面。這是 count-malloc.c 程式碼[4]。

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

Mallocs: 33901
Reallocs: 5
Callocs: 24
Strdups: 31
Wcsdups: 0
Frees: 33956
Allocations: 33961
Maximum allocated: 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
Maximum allocated: 153247

我不敢置信地重複看了兩次。發生什麼事了嗎？為了仔細檢查，我最好再運行一次。無論我運行多少次，結果還是一樣的。

在典型的傳輸中curl_multi_wait() 被呼叫了很多次，並且在傳輸過程中至少要正常進行一次記憶體分配操作，因此刪除那個單一的微小分配操作對計數器有非常大的影響。正常的傳輸也會做一些將資料移入或移出鍊錶和雜湊操作，但是它們現在也大都是無 malloc 的。簡單來說：剩餘的分配操作不會在傳輸循環中執行，所以它們的重要性不大。

先前的 curl 是目前範例分配操作數量的 263 倍。換句話說：新的是舊的分配操作數量的 0.37％ 。

另外还有一点好处，新的内存分配量更少，总共减少了 7KB（4.3％）。

在几个 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 字节。

一点也不难，非常简单。然而，有趣的是，在这个旧项目中，仍然有这样的改进空间。我有这个想法已经好几年了，我很高兴我终于花点时间来实现。感谢我们的测试套件，我可以有相当大的信心做这个“激烈的”内部变化，而不会引入太可怕的回归问题。由于我们的 API 很好地隐藏了内部，所以这种变化可以完全不改变任何旧的或新的应用程序……

（是的，我还没在版本中发布该变更，所以这还有风险，我有点后悔我的“这很容易”的声明……）

curl 的 git 仓库从 7.53.1 到今天已经有 213 个提交。即使我没有别的想法，可能还会有一次或多次的提交，而不仅仅是内存分配对性能的影响。

还有其他类似的情况么？

也许。我们不会做很多性能测量或比较，所以谁知道呢，我们也许会做更多的愚蠢事情，我们可以收手并做得更好。有一个事情是我一直想做，但是从来没有做，就是添加所使用的内存/malloc 和 curl 执行速度的每日“监视” ，以便更好地跟踪我们在这些方面不知不觉的回归问题。

（关于我在 hacker news、Reddit 和其它地方读到的关于这篇文章的评论）

有些人让我再次运行那个 80GB 的下载，给出时间。我运行了三次新代码和旧代码，其运行“中值”如下：

旧代码：

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

新代码：

real    0m29.032s
user    0m12.196s
sys     0m12.820s

承载这个 80GB 文件的服务器是标准的 Apache 2.4.25，文件存储在 SSD 上，我的机器的 CPU 是 i7 3770K 3.50GHz 。

有些人也提到 alloca() 作为该补丁之一也是个解决方案，但是 alloca() 移植性不够，只能作为一个孤立的解决方案，这意味着如果我们要使用它的话，需要写一堆丑陋的 #ifdef。

以上是優化curl的記憶體分配操作的詳細內容。更多資訊請關注PHP中文網其他相關文章！