未使用的 using 指令如何影响性能？
每当您创建新页面或项目时，Visual Studio 都会自动为您创建 using 语句。 其中一些你永远不会使用。
Visual Studio 具有“删除未使用的使用”的有用功能。
我想知道如果从未访问过的 using 语句仍然保留在文件顶部，是否会对程序性能产生负面影响。
Visual Studio will automatically create using statements for you whenever you create a new page or project. Some of these you will never use.
Visual Studio has the useful feature to "remove unused usings".
I wonder if there is any negative effect on program performance if the using statements which are never accessed, remain mentioned at the top of the file.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
未使用的 using 不会影响应用程序的运行时性能。
它会影响 IDE 和整个编译阶段的性能。 原因是它创建了一个必须在其中进行名称解析的附加命名空间。 然而，这些往往很小，在大多数情况下不会对您的 IDE 体验产生明显影响。
出于同样的原因，它还会影响调试器中计算表达式的性能。
An unused using has no impact to the runtime performance of your application.
It can affect the performance of the IDE and the overall compilation phase. The reason why is that it creates an additional namespace in which name resolution must occur. However these tend to be minor and shouldn't have a noticeable impact on your IDE experience for most scenarios.
It can also affect the performance of evaluating expressions in the debugger for the same reasons.
不，这只是编译时/编码风格的事情。 .NET 二进制文件在底层使用完全限定名称。
No, it's just a compile-time/coding style thing. .NET binaries use fully qualified names under the hood.
以下链接 值得一读为什么要删除未使用的引用 解释了从应用程序中删除未使用的引用有何用处。
以下是链接的一些摘录：
通过删除应用程序中任何未使用的引用，您可以
防止
CLR加载未使用的引用模块运行。 这意味着您将减少您的启动时间
应用程序，因为加载每个模块需要时间并避免
让编译器加载永远不会使用的元数据。 您可以
发现根据每个库的大小，你的启动时间
明显减少。 这并不是说您的应用程序将
加载后速度会更快，但是知道您的
启动时间可能会减少。
删除任何未使用的引用的另一个好处是，您将
减少与命名空间冲突的风险。 例如，如果您
同时引用了
System.Drawing和System.Web.UI.WebControls，您可能会发现在尝试引用时会发生冲突
图像类。 如果您的类中有匹配的 using 指令这些引用，编译器无法判断使用哪一个。
如果您在开发时经常使用自动完成功能，请删除未使用的
命名空间将减少您的自动完成值的数量
键入时使用文本编辑器。
The following link A good read on why to remove unused references explains how it be useful to remove unused references from the application.
Below are the some excerpts from the link:
By removing any unused references in your application, you are
preventing the
CLRfrom loading the unused referenced modules atruntime. Which means that you will reduce the startup time of your
application, because it takes time to load each module and avoids
having the compiler load metadata that will never be used. You may
find that depending on the size of each library, your startup time
is noticeably reduced. This isn't to say that your application will
be faster once loaded, but it can be pretty handy to know that your
startup time might get reduced.
Another benefit of removing any unused references is that you will
reduce the risk of conflicts with namespaces. For example, if you
have both
System.DrawingandSystem.Web.UI.WebControlsreferenced,you might find that you get conflicts when trying to reference the
Imageclass. If you have using directives in your class that matchthese references, the compiler can't tell which of the ones to use.
If you regularly use autocomplete when developing, removing unused
namespaces will reduce the number of autocompletion values in your
text editor as you type.
对执行速度没有影响，但可能对编译速度/智能感知有一些轻微影响，因为有更多潜在的命名空间来搜索正确的类。 我不会太担心它，但您可以使用“组织使用”菜单项来删除和排序使用语句。
No effect on execution speed, but there may be some slight effect on compilation speed/intellisense as there are more potential namespaces to search for the proper class. I wouldn't worry too much about it, but you can use the Organize Usings menu item to remove and sort the using statements.
不执行的代码不会影响程序的性能。
Code that does not execute does not affect the performance of a program.
不，编译程序时涉及多个过程。 当编译器开始查找引用（类、方法）时，它将仅使用代码中使用的引用。 using 指令仅告诉编译器要查找的位置。 许多未使用的 using 语句可能会出现性能问题，但只是在编译时。 在运行时，所有外部代码都被正确链接或包含为二进制文件的一部分。
No, there are several process involved when compiling a program. When the compiler start looking for references (classes, methods) it will use only the ones used on the code. The using directive only tells the compiler where to look. A lot of unused using statement could maybe have a performance issue but just at compile time. At runtime, all the outside code is properly linked or included as part of the binary.