【问题标题】:What are some Performance [Dos/Don'ts] in C# -ASP.NETC# -ASP.NET 中有哪些性能 [Dos/Don'ts]
【发布时间】:2009-08-31 23:22:50
【问题描述】:

我正在完成我的一个项目,并查看整个项目以寻找错误、错误和性能错误。我正在使用 MVC。我抓住了一个不要,那就是:

切勿将 RenderPartial 放入循环中。它会大大降低你的整个服务器的速度。

【问题讨论】:

  • RenderPartial 在调试模式下明显比在发布模式下更真实。在调试模式下,开销是巨大的,因为它会在每次迭代时探测 ascx。在发布模式下,这是缓存的,所以它通常一点也不坏。

标签: c# asp.net-mvc performance


【解决方案1】:

从不将 WebControl 存储到 Session。

因为它具有对 Page 对象的引用,所以它最终会将 每个 控件存储到会话中。

【讨论】:

  • 另外,它是一个属于页面的组件,所以如果你把它存储在Session状态,然后在另一个页面中尝试使用它,它就不能正常工作了。 (去过那里,做到了...):)
  • 我想尽可能避免会话状态或其他全局状态。与其说是为了性能,不如说是为了一般的可维护性。
【解决方案2】:

不要过早优化。 :) 如果网站性能不佳,请分析代码以确定将时间花在哪里。

【讨论】:

    【解决方案3】:

    您是否通过 FxCop 运行您的程序?它有一套性能规则。

    【讨论】:

      【解决方案4】:

      不要在调试配置中分析或判断性能。调试配置并不打算很快,您可能会得出错误的性能结论(例如部分视图/用户控件很慢的想法;这在调试配置中是正确的,但在发布配置中则不然)。当您配置文件来衡量性能时,您应该使用发布配置,以便您可以看到真正的问题在哪里。

      【讨论】:

      • 非常非常真实。另外,不要忘记以发布模式发布 ;-)
      【解决方案5】:

      不要摆弄显式垃圾收集。

      【讨论】:

        【解决方案6】:

        大多数性能问题是由于磁盘访问或跨网络调用造成的。

        因此,请注意访问文件系统或数据库的方式和频率。您是否需要通过网络拨打如此多的电话,或者您可以在一个电话中完成。

        一个很好的例子:

        • 值存储在会话中
        • 会话配置为使用 SQL 服务器
        • 每十个请求只使用一次值
        • 对于每个请求,将从数据库中读取值然后写入数据库

        在这种情况下,更好的解决方案可能是编写自定义代码来存储和读取值。

        【讨论】:

          【解决方案7】:

          缓存会帮助你提高性能,但你应该小心只在有意义的地方使用它

          【讨论】:

            【解决方案8】:
            【解决方案9】:

            务必使用静态方法 - 但仅限于经常使用该方法时。

            不要将变量标记为静态,除非您真的希望变量的值在所有实例中都相同(另一位开发人员这样做了,我很高兴调试为什么我们只有在多个实例中才会出现奇怪的行为用户点击该网站)。这不是出于性能原因,而是出于好建议。

            【讨论】:

              【解决方案10】:

              在 C# 中,对象总是用 new 创建的。从某种角度来看,这本身就是一个缺点。例如,如果您在循环中创建一个对象(意味着循环中的每次迭代都会创建一个新对象),您可能会减慢您的程序。

              for (int i = 0; i < 1000; ++i)
              {
                 Object o = new Object();
                 //...
              }
              

              而是在循环外创建一个实例。 对象 o = new Object();

              Object o = new Object();
              for (int i = 0; i < 1000; ++i)
              {
                 //...
              }
              

              只有在你真的需要时才在循环中创建一个对象......

              也许做一点 C++ 可以帮助您了解背后的机制,并知道何时何地优化您的代码。尽管 C++ 是一门不同的语言,但是一旦您了解了内存管理的基础知识(new、delete、指针、动态数组/静态数组等),您就可以将很多东西应用到其他语言中。

              【讨论】:

              • 这正是人们应该避免的性能优化,除非它被证明是一个问题。很多时候,代码只是变得更加复杂,而根本没有提高性能。 C++ 内存管理是一个完全不同的故事......
              • 话虽如此,创建对象真的非常非常便宜。 Ayende 对此进行了介绍:ayende.com/Blog/archive/2008/02/27/…
              • @Erik:如果他的班级真的会做一些严肃的操作,那就不会那么便宜了;)@Alex:对于每一个新的,都必须在某处删除......在 C# 中,垃圾收集器确实为你删除。话虽如此,如果您不断创建和销毁分配大量内存或需要执行某些工作的对象……那么您将一团糟!如果你了解 C++,你就会明白这一点。
              • “对于每一个新的都必须在某处删除......”,错误。垃圾收集它基于遍历根。不“删除”未使用的对象。压缩管理堆并将它们传播到新一代的努力取决于有多少对象仍然是根的,甚至更糟的是固定的。如果不需要最终确定,则被丢弃的对象数量完全无关紧要。以及“......好吧,你会弄得一团糟!”的科学术语。是“内存碎片”。
              • @Alex:如果 C# 中的对象没有被删除,你将会得到一些内存泄漏......垃圾收集器会删除对象。垃圾收集器的优化引擎根据进行的分配确定执行收集的最佳时间(确切的标准由 Microsoft 保护)。当垃圾收集器执行收集时,它会检查托管堆中不再被应用程序使用的对象,并执行必要的操作来回收它们的内存。
              【解决方案11】:

              仅在必要时使用 try/catch 块。它们确实会减慢您的应用程序。

              为清晰而编辑: 我所说的“必要”是指捕捉真正的错误。

              如果您可以编写一些代码并积极主动地确保不会引发错误,那就去做吧,因为它比让异常被引发然后处理它更高效。

              不要使用异常来控制程序流程。我不知道是谁先说的,但我记得“Exceptions should be exception!”这句话。它们应该用于发生不可预见的问题的情况,即在代码执行和抛出它们之前无法测试的事情。

              我经常看到的最糟糕的例子就是这样的事情......

              int i = 0;
              try
              {
                  i = int.Parse(txt);
              } catch {Exception x) {
                  // Do nothing, i = 0
              }
              

              【讨论】:

              • 这当然是更一般规则的特定版本“只编写必要的代码;不必要的代码会减慢您的应用程序”。找出哪些行是“不必要的”是困难的部分。
              • 只有在实际抛出异常时才会产生成本。 try catch 块对您的代码完全没有性能影响。
              • 我想这应该更“只为错误处理抛出异常,而不是为常见的、有效的应用程序流抛出异常,因为抛出异常确实很昂贵。”
              • @Alex 不仅为有效流抛出异常代价高昂,而且乍一看也非常不合逻辑且难以理解。人们往往会忽略的一件事 ;-)
              • 太棒了...澄清含义,但它仍然被否决而没有任何解释...
              猜你喜欢
              • 2010-10-09
              • 1970-01-01
              • 2016-10-29
              • 1970-01-01
              • 2020-08-12
              • 2010-09-05
              • 2011-05-10
              • 2010-09-08
              相关资源
              最近更新 更多