以下是Jeffery先生对拖管代码优势的论述。
如果应用程序在一些新型的CPU（比如奔腾4）上运行，JIT编译器能够检测到这种情况，并产生利用这些新型CPU提供的特殊指令的本地代码。而非拖管应用程序通过被编译为面向具有最小通用功能集合的CPU平台，一般会避免使用新型CPU提供的特殊指令。而这些特殊指令往往会在较新的CPU上为应用程序带来很高的性能提升（前一段时间我还在程序员杂志上看到了intel吹捧使用它自己的C++编译器所编译出来的代码会在它自己生产的CPU上获得多么好的性能。其实Intel完全也可以为JIT来做这样的优化工作，不过这要看.Net平台本身是否留出了这种对JIT类似于插件式支持）。
JIT编译器能检测到正在运行的机器上某些总是返回错误的布尔测试。这样JIT就会将这类不会被执行的代码优化下去，以使代码量变的更小，执行速度变的更快（当我一开始读完这段的时候我对此并不相信，因为我感觉这是一种编译期的技术，一般的非拖管编译器也是可以实现它的，但是当我读完了下面一段后我的观念发生了转变）。
在应用程序运行时，CLR能够分析评估代码的执行情况，并有选择地重新将IL代码编译成为本地代码。根据观察到的执行模式，被编译的代码可以被重新组织以提高分支测试的成功率（这是一个多么令人兴份的技术啊，一种对代码在运行时智能化的分析与调整。这种技术类似于人工智能技术，因为它需要CLR根据运行时根据实际出现的情况来对代码进行调整，不过由于现在人工智能技术还在不断的发展过程中，而且其自身也并不完成熟，所以我想微软可能并不是使用一种智能性质的技术来完成这项工作的。一种可以想象的到，也可以理解的方式是微软将应用中的一些运行时调整方式归结成为“代码运行时调整模式库”，然后CLR再根据这个模式库在运行时对代码进行匹配和调整，在未来，微软可以不断的扩展和完状况这个模式库以使这种优化可以达到一种更好的效果）。