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

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

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

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

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

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

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

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

[代碼]

 IronPython部分的代碼:

[代碼]

 運行結果：

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

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

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

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