繼上次發現URL生成的性能問題之后，我最近一直在關注一些細節的性能優化。這些優化方式不是宏觀的，理論的，而是在實踐上對相同問題的不同做法進行探索。我把探索的過程和結論都發布在博客上了，從結果上看性能提高是比較明顯的。但是，把它們用于解決實際問題時，效果又會如何呢？我把MvcPatch進行了一些修改，然后再使用UrlGenBenchmark進行了一番比較。

對于性能方面的優化，我做了以下一些改進。首先，我使用Fluent Interface來代替原有的Lambda表達式構建方式，期望可以減小表達式樹構建的開銷。此時，原本使用Lambda表達式的做法：

public static string ToPost(this UrlHelper helper, Blog blog, Post post) {return helper.Action<BlogController>(c => c.Post(blog, post)); }

現在就變成了：

public static string ToPostByFluent(this UrlHelper helper, Blog blog, Post post) {return helper.To<BlogController>().Action(c => c.Post, blog, post); }

此外，對于Attribute標記Binder的做法也作了一些處理，不過沒有使用昨天談到的優化方式，而是通過在Model Binder類型標記RunnableAttribute的做法來復用對象。例如：

同時，如果CustomBinderAttribute也被標記了Runnable，那么這個Attribute也可以被復用。如MvcPatch中的BinderAttribute就被標記為Runnable。更細節的做法可參考MvcPatch及UrlGenBenchmark項目的源代碼。

[Reusable] public class PostBinder : IModelBinder, IRouteBinder { ... }

經過測試，我們可以得到如下結果：

將其繪制成圖表：

而每秒生成頁面的數量則是：

從結果上看，Fluent的做法比Lambda的性能有大約30%的提升，但是和Route，尤其是Raw的做法有明顯的差距。在上一篇文章最后我們分析過，使用Lambda構建URL會經歷三個部分，它們所占消耗分別是：

構造表達式樹：約占29%。

解析和運算表達式樹：約占30%。

使用Route生成URL：約占41%。

而使用Fluent Interface時，第一步，即構造對象的階段，其開銷是Lambda表達式的1/3。同時，最后一個步驟的開銷不變。因此我們可以估算出第二個步驟的性能提升程度x：

14.37 / 21.67 = 0.29 / 3 + 0.3 * x + 0.41

等號左邊兩個數字分別是目前Fluent和Lambda兩種做法消耗的時間。通過這個方程我們得出x大約是0.51，也就是說在第二步中我們也獲得了大約50%的性能提高。客觀來說，這個提升還是比較明顯的。不過，絕對來看，這個結果并不讓我十分滿意。不過可能目前還能進行優化的應該是第3個步驟，那么我是否要朝這個方向努力呢？

您可以在這里下載到UrlGenBenchmark V2的代碼，然后通過訪問以下幾個URL來查看各種生成方式的性能：

• /benchmark?iteration=1000&view=ByRaw：使用拼接字符串的方式生成URL
• /benchmark?iteration=1000&view=ByRoute：使用Route生成URL
• /benchmark?iteration=1000：使用Lambda表達式生成URL
• /benchmark?iteration=1000&view=ByFluent：使用Fluent Interface生成URL

相關文章

• 各種URL生成方式的性能對比
• 各種URL生成方式的性能對比（結論及分析）
• 為URL生成設計流暢接口（Fluent Interface）
• URL生成方式性能優化結果
• Route組件GetVirtualPath方法性能優化結果

轉載于:https://www.cnblogs.com/JeffreyZhao/archive/2009/11/19/url-generation-performance-improvement-result.html

總結

以上是生活随笔為你收集整理的URL生成方式性能优化结果的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。