打开View菜单中的Options对话框，在左侧Disassembler选项卡中修改Optimization级别，默认很可能是.NET 3.5，而现在我们要将其修改为None。这么做会让.NET Reflector最大程度地“直接”翻译IL代码，而不做一些额外优化。将Optimization级别设为None以后，DoEnumerable方法的代码就变为了：
static void DoEnumerable(IEnumerable<int> source)
{
int num;
IEnumerator<int> enumerator;
enumerator = source.GetEnumerator();
Label_0007:
try
{
goto Label_0016;
Label_0009:
num = enumerator.Current;
Console.WriteLine(num);
Label_0016:
if (enumerator.MoveNext() != null)
{
goto Label_0009;
}
goto Label_002A;
}
finally
{
Label_0020:
if (enumerator == null)
{
goto Label_0029;
}
enumerator.Dispose();
Label_0029: ;
}
Label_002A:
return;
}
这是C#代码吗？为什么会有那么多的goto？为什么MoveNext方法返回的布尔值可以和null进行比较？其实您把这段代码复制粘贴后会发现，它能够正常编译通过，效果也和刚才的foreach语句完全一样。这就是去除“优化”的效果。老赵在上一篇文章中谈到说：IL和C#一样，都是用于表现程序逻辑。C#使用if...else、while、for等等丰富语法，而在IL中就会变成判断+跳转语句。上面的C#代码便直接保留了IL的这个“特性”。不过还好，我们还是可以看出try...finally，可以看出MoveNext方法和Current属性的访问，可以看到程序使用Console.WriteLine输出数据。至此，我们便发现了foreach语句的真面目。从现在开始，在您准备深入IL之前，老赵也建议您可以尝试一下使用None Optimization来观察C#代码。
实事求是地说，上面的C#代码的“转向逻辑”并不那么清晰，因此您在理解的时候可以把它复制到编辑器中，进行一些简单调整。但是从老赵的经验上来看，需要使用None Optimization进行探索的地方非常少见。foreach是一个，还有便是C#中的其他一些“别名”，如使用using关键字管理IDisposable对象，以及lock关键字。而且，其实这段逻辑也只是没有优化IL中的跳转语句而已，已经比IL本身要直观许多了。此外，关于对象创建，变量声明，方法调用，属性访问，事件加载……一切的一切都还是最常用的C#代码。因为还是那个原因：从大部分情况上来看，IL也只是表现了程序逻辑，并没有比C#等语言体现出更多的细节。
我在这里举了一个较为极端的例子，因为我发现不少朋友并没有尝试过使用None Optimization来观察过代码。这里也可以看出，.NET Reflector的“优化级别”还不够“细致”。不过这应该是一个“产品设计”的正常结果，因为foreach/using/lock的关键字都是从.NET 1.0诞生伊始就存在的，也就是说，即使.NET Reflector选择将IL编译为C# 1.0，它的表现形式依旧是“标准模式”，这方面可能就不能过于强求了吧。至于其他一些探索，例如C#中的自动属性，Lambda表达式构建表达式树或匿名委托，乃至C# 4.0中的dynamic关键字，都是使用.NET 3.5 Optimization进行探索便可得知的结果。您可以回忆一下自己看过的文章，其中有多少是使用IL解释问题的呢？
示例二：学习.NET平台上的其他语言
在.NET平台上，任何语言都会先编译为IL，然后再运行时由JIT转化为机器码。因此有种说法是，只要把握了IL，.NET平台上各种语言之间的迁移都会变得容易。对此老赵有不同看法。在以前讨论语言是否重要的时候，老赵提到，语言它并不仅仅是一种文字表现形式，而是一种“思维方式”的改变，这可能会影响到您程序的编码风格，API设计乃至架构（这个链接可能打不开，因为……）。实际上，如果您只是在C#与VB.NET之间进行迁移，原本就是一件相当容易的事情，因为它们之间“语言”的各种概念和特性都非常接近。而一种改变您思维的语言，才是真正有价值，而且值得进行比较和探索的。如果一味地追求“把握本源”，那么甚至还有比IL更低抽象的事务，但这些就已经违背了“创造一门语言”，以及您学习它的目的了，不是吗？
当然，探索也是需要的，尤其是.NET平台上的各种语言，他们被统一在同样的平台上，这本身就是一种很好的资源。这种资源就是所谓的“比较学习”。您可以把新的语言和您熟悉的语言进行对比，吸收其中的长处（如优秀的思维方式），这样便可以更好地使用旧有语言。例如，您把F#类库转化为C#代码进行观察之后，发现其中大量函数式编程风格的API是使用“委托”来实现的，您可能就会想到是否可以设计出函数式编程风格的C# API，是否可以把F#中List或Seq模块中的各种高阶函数移植到您自己的项目中来。这就有了更好的价值，这价值也不仅仅只是您“学会了新的语言”。
例如，我们现在使用尾递归来计算斐波那契数列。在之前的文章中，我们的作法是：
private static int FibTail(int n, int acc1, int acc2)
{
if (n == 0) return acc1;
return FibTail(n - 1, acc2, acc1 + acc2);
}
public static int Fib(int n)
{
return FibTail(n, 0, 1);
}
为了“尾递归”，我们必须定义一个私有的FibTail方法，接收三个参数。而对外的接口还是一个公有的Fib方法，它返回斐波那契数列第n项的结果。这个示例很简单，作法也没有任何问题。但是老赵有时候会觉得，我们为什么非要定义一个额外的“辅助方法”，然后在现有的方法里只是进行一个简单的转发？如果这个辅助方法会在其他地方得到调用也就罢了（我们遵守了DRY原则），但是现在却有点“平白无故”地在代码里增加了一个方法，这样在VS的Class View或编辑器上方的下拉列表中也会多出一项。此外，为了表示两个方法的关系，您可能还会使用region把它们包裹起来……
不过在F#中，上面的尾递归就可以这样写：
let fib n =
let rec fibTail x acc1 acc2 =
match x with
| 0 -> acc1;
| _ -> fibTail (x - 1) acc2 (acc1 + acc2)
fibTail n 0 1
在fib方法内部，我们可以重新定义一个fibTail方法，其中实现了尾递归。对于外部来说，只有fib方法是公开的，外界丝毫不知道fibTail方法的存在，这种定义内部函数的作法在F#中非常常见。而编译后，我们在.NET Reflector中便可看到与之对应的C#实现：
public static int fib(int n)
{
switch (n)
{
case 0:
return 0;
}
return fibTail@7@7(n - 1, 1, 1);
}
internal static int fibTail@7@7(int x, int acc1, int acc2)
{
...
}
在F#中没有internal的访问级别，您可以认为这里internal便是private。于是我们得知（可能您本身也猜得到）：由于.NET本身并没有“嵌套方法”特性，因此在这里编译器会重新生成一个特殊的私有方法，并且在fib方法里进行调用。于是我们想到，这个“自动生成方法”的特性，在C#中也有体现啊。例如，IEnmuerable<T>有一个扩展方法是Where，我们可以用Lambda表达式构造一个匿名委托作为参数……唔唔，这不就相当于把一个方法定义在另一个方法内部了吗？于是，我们修改一下之前C#的尾递归的实现：
public static int Fib(int n)
{
Func<int, int, int, int> fibTail = null;
fibTail = (x, acc1, acc2) =>
{
if (x == 0) return acc1;
return fibTail(x - 1, acc2, acc1 + acc2);
};
return fibTail(n, 0, 1);
}
如果没有F#的“提示”，可能我们只能想到list.Where(i => i % 2 == 0)这种形式的用法，我们平时不会在方法内部额外地“创建一个委托”，然后加以调用，而且还用到了“递归”——甚至还是“尾递归”（虽然C#编译器在这里没有进行优化，而且这里其实也只是个“伪递归”，因为fibTail其实是个可改变的“函数指针”）。不过，由于我们刚才通过C#来观察F#的编译结果，联想到它和我们以前观察到的C#中“某个特性”非常相似，再加上合理的尝试，最终同样得出了一个还算“令人满意”的使用方式。
这只是一个示例，我并不是说这种作法是所谓的“非常好的实践”。任何办法一旦遭到滥用也肯定不会有好处，您要根据当前情况判断是否应该采取某种作法。刚才的演示只是为了说明，我们应该如何从其他语言中吸取优势思想，改进我们的编程工作。当然，您使用IL来探索新的语言也没有太大问题，C#能看到的东西用IL也可以看到。但是请您回想一下，即使您平时学习IL，您想过直接使用IL来写程序吗？您学习和探索新语言的目的，只是为了搞清楚它的IL表现形式吗？为什么您不使用简单易懂的C#，却要纠缠于IL中那些纷繁复杂的指令呢？
示例三：性能相关
学习IL对写出高性能的.NET程序有帮助吗？
记得以前在学习“计算机系统概论”课程时，有一个实验就是为几段C程序进行优化。当时的手段可谓无所不用其极，例如内联一个子过程以避免call指令的消耗，或把一段C代码使用汇编进行替换等等。从结果上看，它们都能对性能有“明显”的提高。不过，那些都是为了加深概念而进行的练习，并不是说在现代程序中应该使用这种方式进行优化。现在早已不是在“指令级别”进行性能优化的时期了，连操作系统内核也只是在一些对性能要求非常高的地方，如内存管理，线程调度中的细微方面使用汇编来编写，其余部分也都是用C语言来完成。这并不是仅仅是因为“可维护性”等考虑，也有部分原因是因为在目前编译技术的发展下，一些极端的做法已经很难产生有效的优化效果了（例如一般来说来，程序员写出的C代码的性能会优于他写的汇编代码）。
此外，在您不知道JIT究竟作了什么事情的情况下，观察IL这样一种高度抽象的语言，您还是无法真正判断出一个程序从微观上的性能如何。不过这并不是说，现代程序不应该“主动”追究性能，而是说，现代程序在性能优化问题上并非如此简单，它涉及到的东西会更多，需要更加合适的手段。例如，即使您内联了一个子过程，也只是减少了call指令的所带来的消耗，但是这与这个子过程本身“一长串”指令相比，所带来的提高是微乎其微的。而如果您一旦破坏了Locality或造成了False Sharing，或造成了资源竞争等等，这可能就会造成数倍甚至更多的性能损耗。换句话说，影响现代应用程序的性能的因素大都是“宏观”的，用通俗的话来说，一般都是“写法”上造成的问题。
这也是为什么说“Make clean code fast”远比“Make fast code clean”来的容易，现代程序更注重的是“清晰”而并非是“性能”。因为程序清晰，更容易让人发现性能瓶颈究竟在何处，可以进行有针对性地优化（即使是那种在极端性能要求下故意进行的“丑陋”写法，也是为了高性能而“丑陋”，而不是因为“丑陋”而高性能，分清这一点很重要）。换句话说，如果我们有一种更清晰地方式来查看同样的程序实现，不也降低了探索程序性能瓶颈的难度吗？那么，同样一段程序，您会通过C#进行观察，还是使用IL呢？
