improve perf of DWARF2 symbolization: really slow on reporting leaks

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on February 21, 2013 23:42:09_

I noticed what seemed like a huge regression in leak reporting when running
mingw gtk3-demo for issue #1046 . I can repro w/ -leaks_only. I shut down as soon as the window popped up:

% /usr/bin/time ~/drmemory/releases/DrMemory-Windows-1.5.0-5/bin/drmemory.exe -leaks_only -batch -- ./gtk3-demo
18 unique, 54 total, 4298 byte(s) of leak(s)
302 unique, 328 total, 17617 byte(s) of possible leak(s)
ERRORS IGNORED:
12823 still-reachable allocation(s)
0.00user 0.00system 0:05.01elapsed 0%CPU (0avgtext+0avgdata 204800maxresident)k

% /usr/bin/time ~/drmemory/git/build_x86_dbg/bin/drmemory.exe -leaks_only -dr d:/derek/dr/git/exports -batch -- ./gtk3-demo
18 unique, 56 total, 5045 byte(s) of leak(s)
355 unique, 383 total, 19457 byte(s) of possible leak(s)
ERRORS IGNORED:
17 ignored assumed-innocuous system leak(s)
12749 still-reachable allocation(s)
0.00user 0.01system 3:06.87elapsed 0%CPU (0avgtext+0avgdata 264960maxresident)k

5 seconds vs 3 minutes!

The difference is that 1.5.0 doesn't load any symbols and so spends no time
symbolizing.

Now, we could say, who cares about perf when there are this many errors:
let's fix the underlying glib issue ( issue #1143 ). But the perf here is almost unacceptably slow: it crawls through the leak reports.

We should have the same perf issue on Linux.

windbg snapshots are always at places like this:
# ChildEBP RetAddr
00 206ed57c 73a52f3c drmemorylib!memset+0x22 [d:\derek\drmemory\git\src\common\utils.c @ 98]
01 206ed9bc 771852f9 drmemorylib!compare_lines+0x3c [d:\derek\dr\git\src\ext\drsyms\drsyms_dwarf.c @ 163]
02 206edad8 73a52bce ntdll!qsort+0xfc
03 206edf58 73a52664 drmemorylib!search_addr2line_in_cu+0xee [d:\derek\dr\git\src\ext\drsyms\drsyms_dwarf.c @ 249]
04 206ee398 73a517a4 drmemorylib!drsym_dwarf_search_addr2line+0xe4 [d:\derek\dr\git\src\ext\drsyms\drsyms_dwarf.c @ 199]
05 206ee3bc 73a4ea97 drmemorylib!drsym_unix_lookup_address+0x74 [d:\derek\dr\git\src\ext\drsyms\drsyms_unix.c @ 534]
06 206ee410 73a4e9fa drmemorylib!drsym_lookup_address_local+0x97 [d:\derek\dr\git\src\ext\drsyms\drsyms_windows.c @ 453]
07 206ee428 7397d1d6 drmemorylib!drsym_lookup_address+0x2a [d:\derek\dr\git\src\ext\drsyms\drsyms_windows.c @ 1132]
08 206ee5c4 73985306 drmemorylib!lookup_func_and_line+0x366 [d:\derek\drmemory\git\src\common\callstack.c @ 416]
09 206ee700 739871f4 drmemorylib!packed_frame_to_symbolized+0x1256 [d:\derek\drmemory\git\src\common\callstack.c @ 1519]
0a 206ee740 739c49ef drmemorylib!packed_callstack_to_symbolized+0x324 [d:\derek\drmemory\git\src\common\callstack.c @ 1560]
0b 206ee8f4 7399cfb0 drmemorylib!report_leak+0xd1f [d:\derek\drmemory\git\src\drmemory\report.c @ 2686]
0c 206ee954 739dbd46 drmemorylib!client_found_leak+0x300 [d:\derek\drmemory\git\src\drmemory\alloc_drmem.c @ 2351]
0d 206eea34 739387c9 drmemorylib!malloc_iterate_cb+0xaf6 [d:\derek\drmemory\git\src\drmemory\leak.c @ 1205]
0e 206eea70 739386b2 drmemorylib!malloc_iterate_internal+0x109 [d:\derek\drmemory\git\src\common\alloc.c @ 3787]
0f 206eea84 739369a1 drmemorylib!malloc_wrap__iterate+0x12 [d:\derek\drmemory\git\src\common\alloc.c @ 3800]
10 206eea94 739d4d59 drmemorylib!malloc_iterate+0x11 [d:\derek\drmemory\git\src\common\alloc.c @ 3267]
11 206eed74 7399d084 drmemorylib!leak_scan_for_leaks+0x15d9 [d:\derek\drmemory\git\src\drmemory\leak.c @ 1420]
12 206eed80 7380aab3 drmemorylib!check_reachability+0x34 [d:\derek\drmemory\git\src\drmemory\alloc_drmem.c @ 2385]
13 206eed8c 6afedef6 drmemorylib!event_exit+0x33 [d:\derek\drmemory\git\src\drmemory\drmemory.c @ 402]

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1144_