I’ve recently been working on improving (i.e. decreasing) the overheads of sanitization on some embedded systems, and I’ve been using the SPECCPU 2017 benchmarks to try to characterize the performance of code instrumented by different sanitizers.
Recently, I realized that I had never tried to isolate the effect of the sanitizer common infrastructure, in particular, the allocation code. I set up a simple test where I stripped all the leak-checking components out of LSan to give a generic sanitizer shell that is effectively just a thread-safe replacement for the system allocator.
I was surprised to see how large the overhead of just switching to the sanitizer_common allocator is versus using e.g. malloc() and free() from libc. To reiterate, this “sanitizer” is doing nothing other than installing interceptors for the libc functions which handle allocation, and redirecting them to calls into the sanitizer_common allocator code, which is configured exactly as it is in LSan.
Does anyone monitor the sanitizer code for performance regressions / would anyone be interested in setting up some kind of pipeline that does so?