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

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

我構(gòu)思的實(shí)驗(yàn)覆蓋到下面幾個(gè)我認(rèn)為是實(shí)際項(xiàng)目中比較有代表性的場景：

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

2. 生成并操作一個(gè)列表;

3. 生成并操作一個(gè)字典;

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

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

[代碼]

 IronPython部分的代碼:

[代碼]

 運(yùn)行結(jié)果：

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

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

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

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