需要一种优化堆使用率的方法C-Freebsd/glibc

我有一个应用程序，它读取外部xml文件，解析内容并创建列表。 外部供应商经常更新该文件。因此，我无法控制文件的条目/内容数量。我的问题是，我的应用程序使用的内存量不大，这在ps Aux输出（RSS COLUMN）中得到了证明。我追溯到这样一个事实：在解析文件时，我的应用程序链接到libxml2.so.3

它用于解析xml文件，罪魁祸首函数的概要如下所示：

processxml_func（）{

然后编码到

 2)  parse the xml contents --> again using libxml calls and create the list(using malloc) . List has members like name(variable length), description (again variable length etc). This list is long living and needs to live until the program terminates.

 3) Free the memory allocated in 1.

processxml函数结束

使用pmap，我跟踪到调用processxml_func后，我的程序堆内存增加了约10 MB。通过gdb单次跟踪，我注意到：

step1: allocated 7MB --> usage of the heap is 7MB
step2: allocates 3 MB --> usage of the heap is 7+3 MB
step3: free memory in step1 --> usage is still 10MB

我觉得堆使用率在3之后仍然是10MB的原因是，在2期间，我们从步骤1中的碎片块/剩余部分为步骤2分配了一些内存，因此 即使在第3步之后，我们也无法释放整个7MB。我注释掉了第2步，并检查了这一点 退出函数后，堆使用率接近于零

鉴于上述情况，我需要建议/调整以减少应用程序的堆足迹。 我考虑的一种方法是为processxml_func创建一个新流程（fork），然后 使用IPC将列表转移到父进程（父进程中需要重新构建列表）并终止子进程

只是想知道，a）是否有更好的方法来做这件事 b） 控制malloc行为的一些标志

谢谢你抽出时间

我的环境：

---

C语言/FreeBsd，/usr/lib/libc.so.6

一般的解决方案不是将完整的文件读入内存。而是读取一个块，提取所需的内容，再读取一些，再提取一些。您的XML解析器必须支持这种模式

谷歌搜索“流式XML解析器”给出了许多结果，这似乎表明这种情况并不少见

10MB看起来几乎没什么。我不会担心，除非该文件预计会增长到GB区域。

Mini-XML（）

---

我向您推荐这个xml解析器，我在我的docsis NMS应用程序中使用这个xml库（在Debian 7.0下）差不多两年了。我认为它的文档很好，易学，API也很稳定。

你为什么担心？你的机器有这么多限制吗？有了虚拟机，免费的7Mb块基本上什么都不用花。如果你真的需要担心，那么一个简单的解决方案就是在解析之前为列表预先分配内存。你的机器有这么多缺点吗训练有素？是的，这是一种嵌入式环境，当我们试图加快进程时，每MB对我们来说都很重要。我真的无法预先分配，因为我没有列表的大小（注意列表依赖于外部因素的一点）Srinivas：我关心FreeBSD和这个问题，如果你发现一些有用的东西，请告诉我。谢谢。

step1: allocated 7MB --> usage of the heap is 7MB
step2: allocates 3 MB --> usage of the heap is 7+3 MB
step3: free memory in step1 --> usage is still 10MB