Hello World
Spiga

各种URL生成方式的性能对比

2009-10-30 00:31 by 老赵, 18680 visits

上一篇文章中我们列举了各种URL生成的方式,其中大致可以分为三类:

  1. 直接拼接字符串(方法一及方法二)
  2. 使用Route规则生成URL(方法三)
  3. 使用Lambda表达式生成URL(方法四及方法五)

我们可以轻易得知,这3种作法可维护性依次增加,而性能依次减少。不过,我们还是有一个疑问,这个性能究竟相差多少?它是否的确真的可以被忽略?为此,我们还是来进行一次性能对比吧。

测试对象

为了获得贴近实际的测试结果,我打算以我的博客首页作为测试对象。您可以发现,这个页面上的链接非常多,我把它分为三个部分:

  1. 文章(Post)列表:主体部分的40篇文章,其中每篇文章包含1个详细页链接以及5个Tag。
  2. 边栏文章列表:假设边栏列举了120篇文章的链接。
  3. 归档(Archive)列表:也就是每个月的文章链接,3年共36个链接。

作为一个演示,我也精心准备了四种URL模式,它们分别是:

// 博客首页
routes.MapRoute(
    "Blog.Index",
    "{blog}",
    new { controller = "Blog", action = "Index" });

// 标签页
routes.MapRoute(
    "Blog.Tag",
    "{blog}/tag/{tag}",
    new { controller = "Blog", action = "Tag" });

// 按月归档页
routes.MapRoute(
    "Blog.Archive",
    "{blog}/archive/{year}/{month}.html",
    new { controller = "Blog", action = "Archive" });

// 文章详细页
routes.MapRoute(
    "Blog.Post",
    "{blog}/archive/{*post}",
    new { controller = "Blog", action = "Post" });

以上代码在Web项目中的GlobalApplication.cs文件中。您可以发现,我完全按照博客园在定制URL的模式。我想说明的是,其实URL Routing完全非常灵活,您可以根据需求使用各种形式的URL,关键只是“规则配置”而已。不过虽然配置了4种Route规则,但是我只实现了BlogController下的一个Action:博客首页(Index),如下:

[RouteName("Blog.Index")]
public ActionResult Index(
    [ModelBinder(typeof(BlogBinder))]Blog blog, string view)
{
    var model = new IndexModel { Blog = blog, Posts = GetPosts() };
    return View("Index" + view, model);
}

private static List<Post> GetPosts()
{
    ...
}

[RouteName("Blog.Post")]
public ActionResult Post(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    [ModelBinder(typeof(PostBinder))]Post post)
{
    throw new NotImplementedException();
}

[RouteName("Blog.Tag")]
public ActionResult Tag(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    [ModelBinder(typeof(StringBinder))]string tag)
{
    throw new NotImplementedException();
}

[RouteName("Blog.Archive")]
public ActionResult Archive(
    [ModelBinder(typeof(BlogBinder))]Blog blog,
    int year,
    int month)
{
    throw new NotImplementedException();
}

BlogController.cs文件处于Web.Controllers项目中。我为每个复杂参数都安排了ModelBinder,具体实现都很简单,您可以下载文末的代码进行浏览。在GetPosts里我将准备40个Post对象,每个Post对象分配5个Tag,这些都将显示在页面上。Index方法的参数view通过Query String进行传递,例如,您可以通过一下三个链接来访问不同的URL生成方式:

  • /jeffz?view=ByRaw:使用拼接字符串的方式生成URL
  • /jeffz?view=ByRoute:使用Route规则生成URL
  • /jeffz:使用Lambda表达式这个“推荐方式”生成URL

三种方式

在Web.UI项目中的Views目录下有BlogController所使用的三个视图模板,他们使用不同的方式来生成完全一样的内容。例如Index.aspx文件中的定义是这样的:

<!-- 主体文章列表,40篇,各5个Tag -->
<h2>Posts</h2>
<ul>
    <% foreach (var post in Model.Posts) { %>
        <li>
            Title: <a href="<%= Url.ToPost(Model.Blog, post) %>"><%= Html.Encode(post.Title) %></a>
            Tag: 
            <% foreach (var tag in post.Tags) { %>
                <a href="<%= Url.ToTag(Model.Blog, tag) %>"><%= Html.Encode(tag) %></a> | 
            <% } %>
        </li>
    <% } %>
</ul>

<!-- 边栏文章列表,共计120篇 -->
<h2>More post links</h2>
<ul>
    <% for (int i = 0; i < 3; i++) { %>
        <% foreach (var post in Model.Posts) { %>
            <li style="display: inline;">
                <a href="<%= Url.ToPost(Model.Blog, post) %>"><%= Html.Encode(post.Title) %></a> |
            </li>
        <% } %>
    <% } %>
</ul>

<!-- 归档列表,3年共计36个链接 -->
<h2>Archives</h2>
<ul>
    <% for (int year = 2007; year <= 2009; year++) { %>
        <% for (int month = 1; month <= 12; month++) { %>
            <li>
                <a href="<%= Url.ToArchive(Model.Blog, year, month) %>"><%= year %><%= month %></a>
            </li>
        <% } %>
    <% } %>
</ul>

对于IndexByRaw.aspxIndexByRoute.aspx来说,它们只是把ToPost,ToTag等方法改为对应的ToPostByRaw或ToTagByRoute而已。因此,其实生成URL的关键还在于这些辅助方法。例如ToPost,ToTag和ToArchive三个扩展方法是这样实现的:

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

public static string ToTag(this UrlHelper helper, Blog blog, string tag)
{
    return helper.Action<BlogController>(c => c.Tag(blog, tag));
}

public static string ToArchive(this UrlHelper helper, Blog blog, int year, int month)
{
    return helper.Action<BlogController>(c => c.Archive(blog, year, month));
}

可见,使用Lambda表达式构造URL的代码非常清晰,简单,直观——因为Action辅助方法会自动从Lambda表达式中提取Controller和Action名,并调用每个参数的RouteBinder实现复杂类型参数的双向转化,它不需要我们关心更多的东西。

而如果直接拼接字符串,那么它可能就是这样的:

public static string ToTagByRaw(this UrlHelper helper, Blog blog, string tag)
{
    return blog.Alias + "/tag/" + HttpUtility.UrlEncode(tag);
}

而基于Route构造URL就会显得略麻烦一些:

public static string ToTagByRoute(this UrlHelper helper, Blog blog, string tag)
{
    var path = helper.RouteCollection.GetVirtualPathEx(
        helper.RequestContext,
        "Blog.Tag",
        new RouteValueDictionary
        {
            { "controller", "Blog" },
            { "action", "Tag" },
            { "blog", blog.Alias },
            { "tag", HttpUtility.UrlEncode(tag) }
        });

    return path.VirtualPath;
}

至于后两种方式的其它几个辅助方法,您可以下载文末的代码进行浏览,它们都在Web.Controllers项目中的UrlGenExtensions.cs文件中。

运行测试

我们使用BlogController中另一个Action方法:Benchmark进行性能测试。Benchmark方法接受两个参数,一个是循环次数,而另一个则是测试目标:

public ActionResult Benchmark(int iteration, string view)
{
    var model = new IndexModel
    {
        Blog = new Blog { Alias = "jeffz" },
        Posts = GetPosts()
    };

    var result = new BenchmarkModel
    {
        Iteration = iteration,
        View = "Index" + view
    };

    var viewInstance = new WebFormView("~/Views/Blog/Index" + view + ".aspx");

    var viewContext = new ViewContext(
        this.ControllerContext,
        viewInstance,
        new ViewDataDictionary(model),
        new TempDataDictionary());

    // warm up
    viewInstance.Render(viewContext, new StringWriter());

    GC.Collect();

    var watch = new Stopwatch();
    watch.Start();

    for (int i = 1; i <= iteration; i++)
    {
        viewInstance.Render(viewContext, new StringWriter());

        if (i % 100 == 0)
        {
            result.Add(i, watch.Elapsed);
        }
    }

    watch.Stop();

    return View(result);
}

于是,您可以使用下面的链接观察使用三种方法生成1000次页面所消耗的时间:

  • /benchmark?iteration=1000&view=ByRaw:使用拼接字符串的方式生成URL
  • /benchmark?iteration=1000&view=ByRoute:使用Route生成URL
  • /benchmark?iteration=1000:使用Lambda表达式生成URL

Benchmark方法会每隔100次记录一下结果,因此上面的链接加载完后会出现10条信息——这便是我们得到的结果。

结果

至于最终的结果以及分析,我打算暂时卖个关子,不多久我就会独立开篇进行说明的。您可以在这里下载到整个解决方案,代码不多,但也花费了我2个小时进行准备,您可以亲自试验一下。您直接使用上面的Benchmark链接进行观察即可,生成1000次页面已经足以展示一些问题了——不过在此之前,您不妨进行一个预测,猜猜看它们之间究竟有多大的性能差距。

相关文章

Creative Commons License

本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名赵劼(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言

Add your comment

31 条回复

  1. EricZhang(T2噬菌体)
    *.*.*.*
    链接

    EricZhang(T2噬菌体) 2009-10-30 00:33:00

    坐个大沙发,然后再看

  2. 老赵
    admin
    链接

    老赵 2009-10-30 00:45:00

    @EricZhang(T2噬菌体)
    还是你的文章写的好,我现在是想到什么写什么,干了什么写什么,随意性很大,呵呵。

  3. Anytao
    *.*.*.*
    链接

    Anytao 2009-10-30 00:50:00

    睡前,看看,我也喜欢随意性。

  4. 老赵
    admin
    链接

    老赵 2009-10-30 00:55:00

    @Anytao
    随意就写不了书了,hoho。

  5. Ivony...
    *.*.*.*
    链接

    Ivony... 2009-10-30 01:07:00

    这么多夜猫子,半夜都抢不到沙发。。。。。

  6. Otis's Technology Spac…
    *.*.*.*
    链接

    Otis's Technology Space 2009-10-30 03:16:00

    我给懒人贴个结果. ^_^

    Render IndexByRaw for 1000 times:
    •100: 00:00:00.1600495
    •200: 00:00:00.3228959
    •300: 00:00:00.4850814
    •400: 00:00:00.6524022
    •500: 00:00:00.8161370
    •600: 00:00:00.9773995
    •700: 00:00:01.1446405
    •800: 00:00:01.3083665
    •900: 00:00:01.4704034
    •1000: 00:00:01.6385245

    Render IndexByRoute for 1000 times:
    •100: 00:00:01.0544479
    •200: 00:00:02.1161260
    •300: 00:00:03.1705494
    •400: 00:00:04.2248878
    •500: 00:00:05.2907826
    •600: 00:00:06.3411062
    •700: 00:00:07.3988522
    •800: 00:00:08.4616048
    •900: 00:00:09.5238813
    •1000: 00:00:10.5816327

    Render Index for 1000 times:
    •100: 00:00:02.2492656
    •200: 00:00:04.5529318
    •300: 00:00:07.0609507
    •400: 00:00:09.5867197
    •500: 00:00:12.1248048
    •600: 00:00:14.6582865
    •700: 00:00:16.8826530
    •800: 00:00:19.0017236
    •900: 00:00:21.1270754
    •1000: 00:00:23.2580617

  7. leeolevis
    *.*.*.*
    链接

    leeolevis 2009-10-30 08:51:00

  8. 老赵
    admin
    链接

    老赵 2009-10-30 09:07:00

    @Otis's Technology Space
    太不厚道了,要给大家更多自己尝试的机会嘛。

  9. Jeffrey Chan
    *.*.*.*
    链接

    Jeffrey Chan 2009-10-30 09:38:00

    看来还是直接字符串性能更快呀,赵帅难道在下一篇要为lambda做一些优化?

  10. 老赵
    admin
    链接

    老赵 2009-10-30 09:49:00

    @Jeffrey Chan
    你如果不能在实验之间就推断出来字符串性能最快,说明你根本没有想过这个问题……
    Lambda优化早着,因为问题很严重,不是优化能解决的,要有方向性调整。
    下一篇的目的只是揭露问题有多么严重。

  11. Jeffrey Chan
    *.*.*.*
    链接

    Jeffrey Chan 2009-10-30 10:22:00

    亲自实验了一下,Lambda生成url不能接受,要一分钟左右.ByRoute可以接受.问题的严重点是在于你的mvcpatch里面的扩展还是asp.net mvc本身的原因?

  12. Net泡
    *.*.*.*
    链接

    Net泡 2009-10-30 10:26:00

    怎么越来越强了.

  13. 老赵
    admin
    链接

    老赵 2009-10-30 10:42:00

    @Jeffrey Chan
    问题在于Lambda表达式的使用本身有不可回避的硬伤,所以我说必须有方向性的改变。

  14. Otis's Technology Spac…
    *.*.*.*
    链接

    Otis's Technology Space 2009-10-30 10:43:00

    @Jeffrey Zhao
    ^_^

    我是觉得很多人会像我这样,只跑一遍看结果.不会去想太多.
    如果真有想研究的人,还是会去下载的.

  15. EricZhang(T2噬菌体)
    *.*.*.*
    链接

    EricZhang(T2噬菌体) 2009-10-30 11:26:00

    Jeffrey Zhao:
    @EricZhang(T2噬菌体)
    还是你的文章写的好,我现在是想到什么写什么,干了什么写什么,随意性很大,呵呵。



    呵呵,你的文章很好啊,往往对一个点或细节研究描述很深刻,看后也很有收获。

  16. -==NoWay.==-
    *.*.*.*
    链接

    -==NoWay.==- 2009-10-30 13:58:00

    这种性能在实际应用中可以忽略不计了。

  17. 老赵
    admin
    链接

    老赵 2009-10-30 14:17:00

    -==NoWay.==-:这种性能在实际应用中可以忽略不计了。


    您仔细算一下,使用Lambda表达式的方式,生成1000张页面需要20秒,这样每秒只能生成50张页面,如果是双核也只有100张。事实上,我们不可能把所有资源都用来生成页面,所以其实在实际使用中,可能只能扛起的页面更少。
    所以,这不是可以忽略不计的性能开销。
    事实上,我觉得Route的性能也不够好,我认为这是实现上的问题,如果实现的好,性能可以倍增吧——我猜的。

  18. benfeng
    *.*.*.*
    链接

    benfeng 2009-10-30 16:11:00

    等待博主的下一篇文章.

  19. 怪怪
    *.*.*.*
    链接

    怪怪 2009-10-30 19:23:00

    @EricZhang(T2噬菌体)
    你对老赵的特点挖掘的十分精辟,我也是这样被老赵吸引的 ^^

    @Jeffrey Zhao
    代码粗粗看了一遍,但是后两种模式的效率都可以通过优先计算解决。优先级算的方式分为两种:编译期和运行期。

    运行期的方法,第三种一个可想的方式是第一次运行,得到表达式树后,并不是进行生成URL的过程,而是生成一个比如像第一种方法那样生成字串的方法,或者任何一种既高效又结合其它考虑的、组合了其它部件的方法。以后再运行时,就直接使用这个方法就行了。

    编译期的方法就不用谈了,没什么意思,徒增一个前端的步骤。因为事实上可以像ASP.NET WebForm那样,第一次访问时直接生成一个类,并编译,如果该部分没有变化,则一直使用这个类等等。

    这两种方法,实际上都是多了一个类似编译的过程。区别仅仅是后者在硬盘上写入了生成物,而前者每次Application启动都需要生成一遍。

    这次看你的代码,又学到了一些关于ASP.NET MVC的东西。不过这玩意有点太复杂了,复杂的我就要看不懂了呵呵。

  20. 老赵
    admin
    链接

    老赵 2009-10-30 20:49:00

    @怪怪
    怪怪果然厉害,把我想过的东西都说了,我可是想了好一会儿啊……
    一开始我想,1) 可以通过PostSharp这样的方式,在post build里修改程序集的IL实现。
    后来我又想,2) 这点能否在运行时搞,就是例如调用ToPost的时候,实际上执行的是另外一段逻辑。
    但是这两种都是我没有尝试过的,技术方面都有困难,asp.net webform说白了是分析页面模板,但是现在的问题是要分析IL,没有搞过……
    还有,如第2种做法,如何hook并替换掉这部分逻辑,我想不出该怎么做。

    目前我打算实现的是第3种,有些绕不过看了你应该就明白是如何实现了:

    private readonly static object ToPostCacheKey = Guid.NewGuid().ToString();
    private readonly static Expression<Action<BlogController, Blog, Post>> ToPostTemplate = (c, blog, post) => c.Post(blog, post);
    public static string ToPost(this UrlHelper helper, Blog blog, Post post)
    {
        // return helper.Action<BlogController>(c => c.Post(blog, post));
        return helper.Action(ToPostCacheKey, () => ToPostTemplate, blog, post);
    }
    
    其中Action的签名是:
    public static string Action(this UrlHelper helper, object cacheKey, Func<Expression> templateGetter, params object[] args)
    

    用Emit生成逻辑,这样就避免了每次都生成表达式树及解析的过程了——这部分逻辑每张页面都要执行成百上千次的话,开销非常可观。
    总之,我现在还没有想到一种又美观(就是易于使用),又快速的方式。

  21. 老赵
    admin
    链接

    老赵 2009-10-30 21:06:00

    @怪怪
    其实asp.net mvc不复杂阿,一会儿就可以把代码看完了,呵呵。
    倒是asp.net mvc 2变得复杂了不少……

  22. 怪怪
    *.*.*.*
    链接

    怪怪 2009-10-30 22:53:00

    啊,有点理解又有点搞不清细节(最近都在非.NET的几角旮旯较劲)。

    不美观不就是在于要让用户参与cacheKey一类的过程..,就没有原来的形式好看了。

    我觉得这个cacheKey得像你原来那个Expression树Cache的做法之类的一样,由你自己生成;或者根本不用这个cacheKey就可以定位。这个地方是得动点巧劲,嘿嘿,你得费点脑子了。

    另外我再提一个我过去常常使用的小技巧:你可以把你自己的方法放一字典或数组里,因为这个方法(比如开始会Emit、最后执行Emit出来的DynamicMethod之类的)是知道这个字典或数组的存在(他是你自己的不是用户的),它可以在执行完、返回值之前,把数组或字典里的自己位置替换成生成后签名相同的那个比如DynamicMethod。

    考虑到用户每次使用是一个新的需求,这个技巧也没有原来那么简单。你得实现一个一定意义上的注册机制,第一步总是会引导到所谓的“自己的方法”:可能是一个含有用户信息的包装;最初是这个包装在数组或者字典内的正确位置上。

    这个方法会被一个固定签名的方法调用,这个固定签名的方法通过在数组或者字典来找到这个方法。第一次调用的是带Emit的,第二次,这个带Emit的方法已经把数组或字典的相同位置的那个方法换成了Emit生成的那个;再调用就是不带有多余的步骤了。

    而这个固定签名的方法是暴露给用户使用的,这样似乎就是透明的了。不知道这个小技巧能不能帮上忙,也许你已经使用过了呵呵。

    P.S. 复杂是指,作为一个用户,跟python的那些MVC框架相比,第一眼望去的感觉(我还得找找.NET的感觉才能找到门路)。

    不过python的那几个MVC我也没真正用过,因为我的东西得自己路由和Dispatch;所以不知道是不是真的比ASP.NET设计和实现的简单。

  23. 老赵
    admin
    链接

    老赵 2009-10-30 23:02:00

    @怪怪
    我真是弱智了,掉套里了。我用cacheKey的目的是避免每次都创建一个表达式树,我试过,其实光是创建表达式树,生成1000次页面都要10秒钟,超过40%,换句话说其实后面的求值过程其实已经挺高效了。

    我用cacheKey和() => XXX这种形式,避免每次生成一个表达式树——其实……更本不需要,反正现在是static,而不像以前那样每次生成。

    而且,反正每次ToPostTemplate都是同一个对象,我就用template参数两者兼顾就行了,甚至我以前那个Expression Tree的Cache都不需要,直接用字典存就行了:

    private readonly static Expression<Action<BlogController, Blog, Post>> ToPostTemplate = (c, blog, post) => c.Post(blog, post);
    public static string ToPost(this UrlHelper helper, Blog blog, Post post)
    {
        return helper.Action(ToPostTemplate, blog, post);
    }
    
    不过其实我觉得比较不美观的是static变量的签名要写好长一个……

  24. 老赵
    admin
    链接

    老赵 2009-10-30 23:05:00

    @怪怪
    你说的这个做法,不就是JIT的做法嘛。第一次方法call的地址是JIT的过程,而以后call的就直接是native code了。
    不过不知道能否用在我这里……我的目标还是如何设计出好看又高效的API,就算背后实现丑陋一些,那也无所谓,对外美观就行了。

  25. 怪怪
    *.*.*.*
    链接

    怪怪 2009-10-30 23:07:00

    @Jeffrey Zhao
    嗯,我刚才也想来着,明明就是同一个对象么...

    我还以为这里头又有什么几角旮旯呢,怕提出来显得幼稚,没敢说 :P

    (呃,.NET已经不敢让我随便说话了,我觉得这就说明它隐藏了一些复杂的东西,以至于在浅显的东西上都得步步为营,不过任何一个语言和开发环境似乎都是这样一步一步可怕起来的)

  26. 怪怪
    *.*.*.*
    链接

    怪怪 2009-10-30 23:08:00

    不过,这个还是让用户多了一步,如果能把这一步也省掉,其实也没啥不好。

    update:
    是和JIT是一个意思(.NET干这事比Java容易多了),我觉得这可以看作一种“鼓励”。

    update:
    你可以再把上面讨论的这些,结合脑袋n年前说的静态类型字典试试,我觉得是条路。

    class Dictionary<Expression<T>> {
    static T cache;
    }

    不知道这个能不能满足需求(也许外加一些其它技巧)。

  27. 老赵
    admin
    链接

    老赵 2009-10-30 23:19:00

    @怪怪
    怎么省啊,我想不出来……主要问题就是,我想把创建Lambda表达式的工作也省了,不能每次都创建一个。
    我也想过:

    helper.Action<BlogController>(() => c => c.Post(blog, post))
    
    但是,如果用户:
    blog2 = ... // 不直接用参数,处理一番
    helper.Action<BlogController>(() => c => c.Post(blog2, post))
    
    我就没法搞了……
    所以我设计一个“Template”,而Template的参数每次都传进去。

  28. 怪怪
    *.*.*.*
    链接

    怪怪 2009-10-30 23:28:00

    看我上面重新编辑的那个内容,不过仅限于,确实类型可以代替实例作为唯一标志的场合。

    现在我对你的问题理解不是特别透彻,对.NET也有点生疏了;只能是靠吃老本给你提供点建议...

    P.S. 咱们鼓捣的这些内容算不算奇技淫巧啊呵呵^^

  29. 老赵
    admin
    链接

    老赵 2009-10-30 23:34:00

    @怪怪
    我觉得已经很奇很淫了,呵呵。
    这个问题下次我会再分析分析,到时候再讨论。
    说不定我详细分析之后会更清楚一些。
    现在不想再评论里捣鼓了,浪费啊,我要写博客,呵呵。

  30. 杨同学
    *.*.*.*
    链接

    杨同学 2009-10-31 10:58:00

    我还没有时间去学asp.net MVC呢,也没碰过lambda expression。嗯,纯支持了!

  31. ChouKei
    *.*.*.*
    链接

    ChouKei 2009-11-03 10:53:00

    大体看了下,没看懂,哎,本来还想跟老赵学学URL重写的,看出来差距了。
    回头再仔细学学。

发表回复

登录 / 登录并记住我 ,登陆后便可删除或修改已发表的评论 (请注意保留评论内容)

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

评论内容(大于5个字符):

  1. Your Name yyyy-MM-dd HH:mm:ss

使用Live Messenger联系我