【问题标题】:Using multiples "usings", how this affect performance?使用多个“使用”,这如何影响性能?
【发布时间】:2009-02-13 10:20:31
【问题描述】:

我不反对使用“Using”语句,但我想知道当我们在另一个中使用它时这会如何影响性能。

例如:

        using (test1 (type1))
        {
            using (test2(type2))
            {
                using (test2(type3))
                {
                }
            }
        }

这个,在 IL 中会这样翻译:

        try
        {
            try
            {
                try
                {
                }
                finally
                {
                }
            }
            finally
            {
            }
        }
        finally
        { 
        }

这会增加程序集的大小,而且我相信会影响应用程序的性能,对吧?

我们不应该使用这个吗?

        type1 test1 = new type1;
        type2 test2 = new type2;
        type3 test3 = new type3;

        try
        {

        }
        finally
        {
          test1.Dispose;
          test2.Dispose;
          test3.Dispose;
        }

【问题讨论】:

    标签: c# clr


    【解决方案1】:

    不,不要使用你的第二种形式。如果test1.Dispose() 出于某种原因抛出异常,test2.Dispose()test3.Dispose() 将不会被调用。

    性能差异(如果有)将是微观的。不要因为微不足道的性能而抛弃正确性:)

    【讨论】:

    • 谢谢,我没想到 ;)。
    • >>不要因为无关紧要的性能而抛弃正确性。今天的一个想法!
    • 我完全同意看这篇文章codinghorror.com/blog/archives/001218.html 以获得另一个“微观优化”
    【解决方案2】:

    我认为您正在寻找以下内容:

    using (test1(type1))
    using (test2(type2))
    using (test3(type3))
    {
        // Code using test1/test2/test3 goes here.
    }
    

    它相当于您问题中的第一个 try-finally 语句,但显然更具可读性。真的不用担心这里的表现;使用嵌套方法(正如之前的海报所指出的那样)是很好的设计实践和健壮的,另外还有易于阅读的代码(感谢 multi-using 语句)。

    【讨论】:

    • 这个仍然会扩展到三个 try/finally 块 - 正如接受的答案中指出的那样是正确的。明显的好处是可读性。
    • 对不起,你是对的。它确实扩展到三个 try-finally 块。
    【解决方案3】:

    我不认为担心程序集的大小是我们通常需要担心的,但会以编写更复杂的代码来维护代码为代价!

    您的示例代码准确地显示了为什么我们需要编译器来生成它所做的代码。如果您对 new type2() 的调用失败,则永远不会调用 test1 上的 Dispose 方法,这将导致资源泄漏。

    【讨论】:

      【解决方案4】:

      除非抛出异常,否则 try/catch/finally 并不昂贵。即便如此,也有几个人(包括 Jon Skeet)说抛出的异常并没有那么昂贵。

      这么说,显然你不应该对控制流使用异常。

      【讨论】:

        猜你喜欢
        • 2010-09-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2010-09-26
        • 2011-07-10
        • 1970-01-01
        • 1970-01-01
        • 2014-02-09
        相关资源
        最近更新 更多