Performance: Optimize translation to support large apps like Chrome and DumpRenderTree

_From [rnk@google.com](https://code.google.com/u/rnk@google.com/) on June 12, 2012 18:19:39_

This is to try to make the hybrid go faster, in particular in the case where we're not doing any instrumentation to the main binary.

This case is more of a container for the ideas we have and profiling results.

We ran DumpRenderTree and found that ~70% of the time was spent in dynamorio and 20% in the code cache for rendering buildbot html docs:

[rnk@wittenberg src]$ perf report | head
# Overhead Command Shared Object Symbol
# ........ ............... ................... .....................................
70.83% DumpRenderTree libdynamorio.so.3.2 [.] 0x8cafb
18.17% DumpRenderTree perf-9392.map [.] 0x725c93d9
2.71% DumpRenderTree [kernel.kallsyms] [k] format_decode
1.06% DumpRenderTree [kernel.kallsyms] [k] number
0.91% DumpRenderTree [kernel.kallsyms] [k] vsnprintf

Unfortunately, perf would not give us symbols so we switch to oprofile and got this profile:
[rnk@wittenberg src]$ opreport -t 1 -l ../../dynamorio/build/install/lib64/release/libdynamorio.so.3.2
samples % symbol name
4971 7.1208 insert_exit_stub_other_flags
2107 3.0182 mutex_lock
2082 2.9824 decode_sizeof
1774 2.5412 build_bb_ilist
1695 2.4280 encoding_possible_pass
1653 2.3679 fragment_lookup_fine_and_coarse
1647 2.3593 instr_encode_common
1502 2.1516 dispatch
1399 2.0040 hashtable_fragment_lookup
1316 1.8851 emit_fragment_common
1140 1.6330 read_lock
1103 1.5800 read_unlock
1078 1.5442 decode_cti
975 1.3966 instr_is_exit_cti
970 1.3895 fcache_return_extra_space
889 1.2735 get_thread_private_dcontext
860 1.2319 fragment_lookup_future
852 1.2205 monitor_cache_enter
828 1.1861 common_heap_alloc
823 1.1789 opnd_type_ok
777 1.1130 our_vsscanf
758 1.0858 size_ok

Highlights:
insert_exit_stub_other_flags: nice hotspot to optimize, probably
mutex_lock: maybe we can acquire less or remove some unnecessary locking
long tail of decode routines: known hotspot, amenable to inlining IR routines (opnd_type_ok, instr_is_exit_cti)
our_vsscanf: !! worrying, this means we're parsing /proc/pid/maps. do that less

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