c/c++中类似于java jprofiler/eclispe memoryanalysis的代码性能瓶颈以及内存泄露分析工具

visual studio有自带的,可以看MSDN,不过一般来说,我们比较关注linux下的,搜了下,比较好用的应该有gprof和valgrind(可以分析内存潜在的泄露,如针对json-c/log4c进行分析),先记录。可参考如下:

http://blog.csdn.net/clarstyle/article/details/41747817?utm_source=itdadao&utm_medium=referral

C++ 性能分析工具调研

http://gernotklingler.com/blog/gprof-valgrind-gperftools-evaluation-tools-application-level-cpu-profiling-linux/

对于性能分析,推荐gcc perf命令行工具(https://zhuanlan.zhihu.com/p/186208907,使用上这个更合适),没有之一。

perf record -a --call-graph dwarf -p PID

perf report

上述命令生成的就是调用链。

# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 411K of event 'cycles:uppp'
# Event count (approx.): 415626554486
#
# Children      Self  Command  Shared Object       Symbol                                 
# ........  ........  .......  ..................  .......................................
#
    86.20%     7.98%  lightdb  lightdb             [.] ReadBuffer_common
            |          
            |--80.75%--ReadBuffer_common
            |          |          
            |           --80.75%--BufferAlloc (inlined)
            |                     |          
            |                     |--38.27%--StrategyGetBuffer
            |                     |          |          
            |                     |           --37.50%--GetBufferFromRing (inlined)
            |                     |                     |          
            |                     |                     |--14.59%--GetCurrCandidateNums
            |                     |                     |          |          
            |                     |                     |           --11.59%--GetPgwrCandidateNums (inlined)
            |                     |                     |                     |          
            |                     |                     |                      --0.89%--pg_atomic_read_u64 (inlined)
            |                     |                     |                                pg_atomic_read_u64_impl (inlined)
            |                     |                     |          
            |                     |                     |--9.72%--LockBufHdr
            |                     |                     |          |          
            |                     |                     |          |--8.18%--pg_atomic_fetch_or_u32 (inlined)
            |                     |                     |          |          pg_atomic_fetch_or_u32_impl (inlined)
            |                     |                     |          |          
            |                     |                     |           --0.54%--init_spin_delay (inlined)
            |                     |                     |          
            |                     |                      --3.85%--pg_atomic_read_u32 (inlined)
            |                     |                                pg_atomic_read_u32_impl (inlined)

 除了动态链路链路外,还可用gnu cflow对单个静态c源文件(虽然单个,但是相比直接看源代码,还是方便很多的)分析调用链路。如下:

[lightdb@lightdb-dev plan]$ /usr/local/cflow/bin/cflow planner.c | more
expression_planner() <Expr *expression_planner (Expr *expr) at planner.c:6319>:
    eval_const_expressions()
    fix_opfuncids()
expression_planner_with_deps() <Expr *expression_planner_with_deps (Expr *expr, List **relationOids, List **invalItems) at planner.c:6346>:
    MemSet()
    eval_const_expressions()
    fix_opfuncids()
    extract_query_dependencies_walker()
plan_cluster_use_sort() <bool plan_cluster_use_sort (Oid tableOid, Oid indexOid) at planner.c:6399>:
    makeNode()
    list_make1()
    setup_simple_rel_arrays()
    build_simple_rel()
    foreach()
    lfirst_node()
    get_relation_data_width()
    cost_qual_eval()
    create_seqscan_path()
    cost_sort()
    create_index_path()
plan_create_index_workers() <int plan_create_index_workers (Oid tableOid, Oid indexOid) at planner.c:6517>:
    makeNode()
    list_make1()
    setup_simple_rel_arrays()
    build_simple_rel()
    table_open()
    index_open()
    is_parallel_safe()
    RelationGetIndexExpressions()
    RelationGetIndexPredicate()
    Min()
    estimate_rel_size()
    compute_parallel_worker()
    index_close()
    table_close()
planner() <PlannedStmt *planner (Query *parse, const char *query_string, int cursorOptions, ParamListInfo boundParams) at planner.c:277>:
    standard_planner() <PlannedStmt *standard_planner (Query *parse, const char *query_string, int cursorOptions, ParamListInfo boundParams) at planner.c:290>:
        makeNode()
        IsParallelWorker()
        max_parallel_hazard()
        subquery_planner() <PlannerInfo *subquery_planner (PlannerGlobal *glob, Query *parse, PlannerInfo *parent_root, bool hasRecursion, double tuple_fraction) at planner.c:608>:
            makeNode()
            memset()
            assign_special_exec_param()
            rt_fetch()
            SS_process_ctes()
            replace_empty_jointree()
            pull_up_sublinks()
            preprocess_function_rtes()
            preprocess_rownum()
            pull_up_subqueries()
            flatten_simple_union_all()
            foreach()
            lfirst_node()
            has_subclass()

 

perf使用可参见:https://blog.csdn.net/jasonactions/article/details/109332167https://perf.wiki.kernel.org/index.php/Main_Page

https://wiki.postgresql.org/wiki/Profiling_with_perf

posted @ 2017-01-25 15:53  zhjh256  阅读(232)  评论(0编辑  收藏  举报