Hi, That's a good question. I'm not aware of a really good
answer though.

The performance hit from SDE is primarily because it is based on
an x86 to x86 JIT called Pin. Pin scans all instructions before
they execute and writes new code which it inserts in to a
software code cache. When Pin encounters an instruction that
requires emulation, SDE requests that Pin insert a branch and
skip that instruction requiring emulation. All that JIT'ing
takes time and the code we generate is not as efficient
generally speaking as the original code. Hence the slow down
that you are observing.

SDE replaced an internal tool that would trap on unknown
instructions and branch to an emulation routine. Because SDE
avoids the trap overhead, we found that it was hundreds of times
faster for some applications that used instructions requiring
emulation in hot loops. The trap-and-emulate approach pays a
big price each time emulation is needed. SDE pays that price
approximately once when JIT'ing but we must JIT all code. A
trap-and-patch solution would avoid the trap overhead on
secondary executions and sometimes works but not all
instructions are patchable (too short) and some clever binaries
branch to the middle of instructions and do other interesting
things that make a simple trap-and-patch approach less than
fully robust.

Modifying binaries typically has legal implications and should
not be discussed here.