I'm often amazed how many people simply are not aware of address sanitizer.
It's orders of magnitude faster than valgrind - and it can find bugs that are simply impossible to find with a runtime-only tool (e.g. most stack oob accesses). However it can't find uninitialized memory (there is msan for that, but that's a bit tricky to set up and not available in gcc).
I think when I tried to use it, it enlarged all my stack allocations. When using precise stack allocations (user threads), it causes all the stacks to blow up.
It think it uses a lot of extra memory as part of a design a tradeoff that keeps CPU overhead to a minimum. The documentation above mentions the memory cost in the limitations section.
By the way, there's a great talk from C++ Going Native 2013, called The Care and Feeding of C++'s Dragons [1] talking about a number new C++ tools, including AddressSanitizer. It's been two years since then, but it's probably still a good introduction.
Dr. Memory and Valgrind both work on unaltered binaries -- quite different tools from a compiler option. I expect that AddressSanitizer is quite a bit faster because it's compiled in.
There's also TSAN for detecting race conditions as well. Personally I've been using valgrind less and less since ASAN and TSAN were released simply because they're so much faster.
While I like -fsanitize=address, the project I spend most of my time on may have tens of thousands of lightweight threads, which makes it a non-starter. Valgrind works fine on it (Albeit at a significant performance impact).
asan and valgrind are complimentary tools; AddressSanitizer catches memory errors and is fast enough that you can keep it turned on and kind of forget about it, but it doesn't catch leaked memory. Valgrind has been indispensable for leak finding for me, and asan hasn't replaced it.
http://clang.llvm.org/docs/AddressSanitizer.html