pprof函数名未翻译、为函数地址0x00000232382788
这几天在分析一个性能未达预期的功能,使用gperftools cpu profiler生成后,使用pprof格式化的时候,发现pprof出的结果函数名未翻译、为函数地址,如下所示:
每个节点代表一个函数,节点数据格式:
Class Name
Method Name
local (percentage) #不包含内部其他函数调用所消耗的CPU时间(内联函数除外)
of cumulative (percentage) #整个函数消耗的CPU时间,包括函数内部其他函数调用所消耗的CPU时间,如果与local相同,则不打印
还有一种形式为0x00000232382788形式,经google以及推测实验,主要是因为相关的动态库没有使用-g编译,或者指定了编译选项-gstabs+所致。
带正确-g调试信息的pprof应该是如下格式:
从其中可知,sprintf占了大约1/3的时间,由于这功能主要是就是导出符合要求的TXT文件,故确实大量使用了sprintf调用,实际上很多调用可以提前预处理好,同时在代码中处理的也是如此。同时因为是好计算的,实际上可能使用strcpy代替可能会更好。strcpy和sprintf的性能测试对比如下:
https://blog.csdn.net/tronteng/article/details/7225577
怎么说呢,相比java的jprofiler,gperftools的分析结果不是特别直观。可能和开源有一定的关系吧,比如j2se自带的jvisualvm对真正性能profiler就不理想。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!