关于IronPython和C#执行速度对比_.Net教程

推荐：解读在Visual C# .NET中跟踪和调试
本文介绍如何使用 Debug 和 Trace 类。Microsoft .NET Framework 中提供了这两个类。在应用程序开发期间或部署到产品后，可以使用这两个类提供有关应用程序性能的信息。这两个类只是 .NET Framework 中所提供配置功能的一部分。 要求下面的列表概括了推荐的

其实我自己对执行速度这个问题本来并没有什么兴趣，因为以前的经验告诉我：除非是运算密集型的程序，否则脚本语言和编译型语言使用起来速度没有多大差别。但是我们公司有个人知道我的想法以后，天天在我耳边嚷嚷脚本运行速度太慢，那好吧，让我用实验来说服你。不过这一试，还真的出现了吓人一跳的结果。

我构思的实验覆盖到下面几个我认为是实际项目中比较有代表性的场景：

1. 访问一个稍大的数据表，遍历所有记录;

2. 生成并操作一个列表;

3. 生成并操作一个字典;

4. 通过反射动态加载并调用一个方法。

C#部分的代码，编译时使用了/debug-和/optimize ：

[代码]

 IronPython部分的代码:

[代码]

 运行结果：

对于列表和字典的操作，IronPython比C#慢3到4倍，这是意料之中的事情。没有想到的是访问数据库的方法，IronPython竟然比C#还要略快，这是事先无论如何都没有料到的。原来我以为，数据库访问代码基本上是纯粹的调用ADO.Net，瓶颈主要是在数据库那一边，IronPython在方法调用的时候应该比C#略微慢一点吧，那么总体速度也应该稍微慢一点才对。没想到结果正好反过来！我也没有办法解释为什么这里IronPython能够做到比C#还快。不过结论应该很明显了：访问数据库的时候，你无需担心IronPython不够快。我们的项目大多数时候效率瓶颈都是出在数据库上面，至于程序语言快一点还是慢一点通常无关紧要，更何况这里的结果表明脚本语言有时候反而可能更快呢。
 

 对于反射的测试，IronPython则是压倒性的战胜了C#。需要说明的一点是我在C#中反射生成对象使用的方法是ConstructorInfo.Invoke()。如果换成Activator.CreateInstance()的话，那么C#的时间将会缩减到230～250毫秒，不过即便这样仍然比IronPython落后一半左右。为什么使用反射时IronPython比C#快这么多呢？或许因为它运行的时候能够在内存中动态生成部分字节码，从而跳过反射环节，所以更快吧。

从这个实验的结果看，IronPython的性能可以说好到超出了我的预期。因为之前也看过其他一些相关的性能评测，比如说Ruby要比Java的运行速度慢30倍（这个比较已经有一段时间了，现在差距应该有所缩小），相比之下IronPython的性能简直可以用十分优异来形容了。当然脚本语言也有一个不足的地方，就是加载解释器的时候会带来几秒钟的固定开销，频繁修改程序的时候，这几秒钟还是有点让人难受的。好在以嵌入方式使用IronPython的时候，引擎只需要加载一次就够了，所以这个缺点大体上还是可以接受的。
 

分享：谈ASP.NET多附件上传和附件编辑的实现
在写这篇文章之前我也在Google上找到了很多有关多附件上传的文章，有用ASP.NET实现的，也有用JSP、PHP等其它技术实现的，但基本前提都是事先通过js脚本来动态创建DOM，然后上传的时候在服务端做一下处理，有点类似于163的邮件系统。文件上传需要通过页面的PO