關(guān)于IronPython和C#執(zhí)行速度對比_.Net教程

推薦：解讀在Visual C# .NET中跟蹤和調(diào)試
本文介紹如何使用 Debug 和 Trace 類。Microsoft .NET Framework 中提供了這兩個類。在應(yīng)用程序開發(fā)期間或部署到產(chǎn)品后，可以使用這兩個類提供有關(guān)應(yīng)用程序性能的信息。這兩個類只是 .NET Framework 中所提供配置功能的一部分。 要求下面的列表概括了推薦的

其實我自己對執(zhí)行速度這個問題本來并沒有什么興趣，因為以前的經(jīng)驗告訴我：除非是運算密集型的程序，否則腳本語言和編譯型語言使用起來速度沒有多大差別。但是我們公司有個人知道我的想法以后，天天在我耳邊嚷嚷腳本運行速度太慢，那好吧，讓我用實驗來說服你。不過這一試，還真的出現(xiàn)了嚇人一跳的結(jié)果。

我構(gòu)思的實驗覆蓋到下面幾個我認為是實際項目中比較有代表性的場景：

1. 訪問一個稍大的數(shù)據(jù)表，遍歷所有記錄;

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

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

4. 通過反射動態(tài)加載并調(diào)用一個方法。

C#部分的代碼，編譯時使用了/debug-和/optimize ：

[代碼]

 IronPython部分的代碼:

[代碼]

 運行結(jié)果：

對于列表和字典的操作，IronPython比C#慢3到4倍，這是意料之中的事情。沒有想到的是訪問數(shù)據(jù)庫的方法，IronPython竟然比C#還要略快，這是事先無論如何都沒有料到的。原來我以為，數(shù)據(jù)庫訪問代碼基本上是純粹的調(diào)用ADO.Net，瓶頸主要是在數(shù)據(jù)庫那一邊，IronPython在方法調(diào)用的時候應(yīng)該比C#略微慢一點吧，那么總體速度也應(yīng)該稍微慢一點才對。沒想到結(jié)果正好反過來！我也沒有辦法解釋為什么這里IronPython能夠做到比C#還快。不過結(jié)論應(yīng)該很明顯了：訪問數(shù)據(jù)庫的時候，你無需擔心IronPython不夠快。我們的項目大多數(shù)時候效率瓶頸都是出在數(shù)據(jù)庫上面，至于程序語言快一點還是慢一點通常無關(guān)緊要，更何況這里的結(jié)果表明腳本語言有時候反而可能更快呢。
 

 對于反射的測試，IronPython則是壓倒性的戰(zhàn)勝了C#。需要說明的一點是我在C#中反射生成對象使用的方法是ConstructorInfo.Invoke()。如果換成Activator.CreateInstance()的話，那么C#的時間將會縮減到230～250毫秒，不過即便這樣仍然比IronPython落后一半左右。為什么使用反射時IronPython比C#快這么多呢？或許因為它運行的時候能夠在內(nèi)存中動態(tài)生成部分字節(jié)碼，從而跳過反射環(huán)節(jié)，所以更快吧。

從這個實驗的結(jié)果看，IronPython的性能可以說好到超出了我的預(yù)期。因為之前也看過其他一些相關(guān)的性能評測，比如說Ruby要比Java的運行速度慢30倍（這個比較已經(jīng)有一段時間了，現(xiàn)在差距應(yīng)該有所縮小），相比之下IronPython的性能簡直可以用十分優(yōu)異來形容了。當然腳本語言也有一個不足的地方，就是加載解釋器的時候會帶來幾秒鐘的固定開銷，頻繁修改程序的時候，這幾秒鐘還是有點讓人難受的。好在以嵌入方式使用IronPython的時候，引擎只需要加載一次就夠了，所以這個缺點大體上還是可以接受的。
 

分享：談ASP.NET多附件上傳和附件編輯的實現(xiàn)
在寫這篇文章之前我也在Google上找到了很多有關(guān)多附件上傳的文章，有用ASP.NET實現(xiàn)的，也有用JSP、PHP等其它技術(shù)實現(xiàn)的，但基本前提都是事先通過js腳本來動態(tài)創(chuàng)建DOM，然后上傳的時候在服務(wù)端做一下處理，有點類似于163的郵件系統(tǒng)。文件上傳需要通過頁面的PO