DynamoRIO / DynamoRIO/drmemory
reduce overhead of malloc tracking
- Dominant language
- C
- Stars
- 2.7k
- Forks
- 290
- PR merge metrics
- No merged PRs in 30d
Description
_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on June 16, 2011 10:24:33_
below are perf numbers for -leaks_only -no_count_leaks vs native.
-no_count_leaks disables stack zeroing, so this is the cost of malloc
tracking (w/o recording callstacks): this is way too high!
this is one barrier to higher performance with -no_check_uninitialized.
> spec2k6cmpave namedres/leaksonly-nocount-ref/ namedres/native-ref/
400.perlbench 3.77 ( 1897 / 503)
401.bzip2 1.10 ( 951 / 865)
403.gcc 1.75 ( 750 / 429)
429.mcf 1.05 ( 393 / 373)
445.gobmk 1.58 ( 1009 / 639)
456.hmmer 1.09 ( 1301 / 1195)
458.sjeng 1.77 ( 1381 / 782)
462.libquantum 1.07 ( 793 / 739)
464.h264ref 1.67 ( 1751 / 1049)
471.omnetpp 3.72 ( 1559 / 419)
473.astar 1.32 ( 874 / 660)
483.xalancbmk 3.81 ( 1331 / 349)
410.bwaves 1.17 ( 875 / 751)
416.gamess 1.16 ( 1610 / 1392)
433.milc 1.14 ( 706 / 620)
434.zeusmp 1.14 ( 910 / 795)
435.gromacs 1.02 ( 1198 / 1170)
436.cactusADM 1.02 ( 1653 / 1617)
437.leslie3d 1.04 ( 851 / 816)
444.namd 1.03 ( 761 / 741)
447.dealII 2.17 ( 1299 / 599)
450.soplex 1.21 ( 488 / 404)
453.povray 1.74 ( 627 / 360)
454.calculix 1.08 ( 1616 / 1497)
459.GemsFDTD 1.05 ( 983 / 935)
465.tonto 4.29 ( 3613 / 842)
470.lbm 1.23 ( 795 / 648)
481.wrf 1.95 ( 2459 / 1258)
482.sphinx3 1.13 ( 840 / 741)
average 1.66
back when we first created Dr. Heapstat I spent some time optimizing malloc
tracking, including recording callstacks, and I sure thought I had
performance better than this (I was looking at spec2000 and some
malloc-intensive benchmarks like roboop and cfrac). something could have
regressed.
from profiling, some of this cost is from maintaining the hashtables and
delay-free queue, much of which could go away w/ malloc replacement b/c the
header could be used more freely: or perhaps a larger redzone could be used
with more data than just the size stored directly in it. early injection
would make that much easier, since today no-redzone allocs must be handled:
one reason for the current design.
_Original issue: http://code.google.com/p/drmemory/issues/detail?id=460_
Contributor guide
Assessment
This issue has not been assessed yet.