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就不理想。

posted @   zhjh256  阅读(1009)  评论(2编辑  收藏  举报
编辑推荐:
· 开发者必知的日志记录最佳实践
· 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 让容器管理更轻松!
点击右上角即可分享
微信分享提示