How to analyze the overhead of ASan

[Issac Torvalds]

Hi,

At first I want to thank all of you for this great tool, it's very useful in debugging.

Compared program instrumented via ASan with original program, we have known
the overhead mainly comes from the following parts:
1) Execution of shadow manipulation
2) Execution of checking whether the memory operation is valid
3) Memory layout change of executable (Compared to original program in memory
layout, instrumented executable additionally has shadow manipulation code,
checking code and shadow region. These part may have impact on cache usage
and cause the performance down)
Because I want to use ASan in my experiment. I want to know the overhead
caused by each parts. I am wondering whether there is any option/way to measure
it.

Thanks a lot

[Dmitry Vyukov]

Hi,

As far as I know, we don't have an existing option to measure it.
You can get some information on overheads by compiling the program
*without* the instrumentation but linking in the runtime library
(however note that runtime does some instrumentation as well -- e.g.
memcpy()). You can break down runtime overheads by commenting out some
parts of code (e.g. shadow poisoning/unpoisoning/stack unwinding).
Also note that asan uses own memory allocator.

[Konstantin Serebryany]

In most cases the major overhead comes from the shadow memory load.
However, if you application is very malloc-intensive, then asan's
malloc may also contribute to slowdown significantly.
I'd recommend using perf
(https://perf.wiki.kernel.org/index.php/Main_Page) or oprofile to get
a profile:
if you see too many functions with "asan" at the top of profile, it
means that the run-time library is a hot spot.

--kcc

> --
> You received this message because you are subscribed to the Google Groups "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to address-saniti...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>