4

在 C# 中，我们编写using System.IO或我们想要使用的任何其他命名空间。

那么这是一个坏习惯，它会影响性能还是记忆？

或者为它们创建包装类并使用它来避免在任何地方使用相同的命名空间是否很好？

4

5 回答 5

2

您可以using在文件顶部添加任意数量的语句，它不会对运行时性能产生一点影响。

然而，为类制作包装器会影响性能，使代码稍微慢一些。不是很多，所以如果它使代码更易于管理，那么你可以很好地使用包装器，但是仅仅为了避免using语句而使用它并不是一个好的理由。

拥有大量using语句可能会在一定程度上影响编译时间，但您必须拥有大量语句才能引起注意。

考虑在 Visual Studio 中使用“删除未使用的 usings”命令，该命令将删除using实际未使用的命名空间的语句。我经常使用它，但只是为了保持文件精简，而不是为了性能。

于 2012-09-08T16:23:00.430 回答
2

在 .Net 中，命名空间始终是每种类型名称的组成部分。但是，如果每次声明某种类型时都必须指定整个命名空间，则会在代码中造成巨大的重复和噪音。这就是 using 指令的用途，它基本上将所有前缀折叠到一个位置，使您可以指定类型的“最后”部分。只有在没有歧义的情况下才能这样做。

然而，编译器并不关心上述内容。因此存在一个预编译阶段，每个依赖于using指令的类型声明都会取回其前缀。

所以当你说：

Using System;

void foo()
{
   String s1 = "bla";
   String s2 = "bli";
}

预编译中发生的事情是将System命名空间附加到每个String声明中，如下所示：

void foo()
{
   System.String s1 = "bla";
   System.String s2 = "bli";
}

直到现在编译器才真正起作用。

所以关于性能，从技术上讲，它会影响构建过程的性能。使用的次数越多，预编译阶段需要做的匹配就越多：所以编译器看到String. 那是什么String？是System.String吗SomeOtherNamespace.String？真正发生的是编译器将它在 using 中找到的每个命名空间附加到类型声明并检查这种类型是否存在。如果是 - 很好，如果不是 - 它会尝试下一个命名空间。

所以你看，如果你有很多文件没有使用过using的声明，编译器必然会做多余的工作。在极端情况下，它会显着降低构建本身的性能。

一般来说，永远不要犹豫使用你正在使用的东西（不是双关语）。但是您应该避免声明不必要using的指令，这不仅是因为对构建持续时间的潜在（不太可能）性能影响，而且还因为您希望保持代码尽可能干净。

于 2012-09-08T16:37:51.357 回答
0

编译器为我们进行优化以包含相关内容assemblies of namespaces where required，因此您不需要包装器进行优化。最好将类所需的所有命名空间包含在using statement on the top.

于 2012-09-08T16:17:19.427 回答
0

您可以使用，不影响您的性能并不重要（您的代码的最佳做法是删除使用未使用的右键单击）

一切都在需要时加载。

于 2012-09-08T16:17:58.880 回答
0

当您使用 System.IO 时；在文件的开头，您告诉 C# 编译器考虑使用该命名空间进行类名查找。它对程序性能完全没有影响。

但是，如果您在同一个文件中创建包装器，您将为使用的每个类创建额外的（即使是很小的）类副本，并且会降低运行时的性能。

于 2012-09-08T16:43:39.587 回答