This issue covers investigating how we can reduce it to around 2x. This is an arbitrary number that we may revisit or not be able to hit, but 3.5x is high enough that it's worth spending effort on this before we send these bytes down the pipe to users.
One area that needs investigation is global instrumentation. Putting redzones around string literals and other globals is very object file format dependent, and it can interfere with normal linker optimizations like string pooling and identical comdat folding (ICF). This can lead to surprising overheads that we don't see on other platforms.
I don't know of any other areas with major room for improvement, but here is a list of features we could consider disabling to shrink the binary:
- asan-globals: Disables instrumentation mentioned above if the overhead can't be reduced or is still too high.
- asan-use-after-return: UAR is probably too expensive for users, but may be very high value, and can be flagged on/off at runtime.
- asan-stack: We want this if at all possible since it will let us see bugs that SyzyASan cannot.
- asan-use-after-scope: Probably not worth disabling, mentioned for completeness.
Some other flags to consider trading size for perf:
- asan-instrumentation-with-call-threshold: Disables inlined checks in large functions. Can be set to 0 to disable inline checks.
We're still searching for an owner for this, so I'm marking it as available.
Comment 1 by sheriffbot@chromium.org
, Nov 21Status: Untriaged (was: Available)