从其他程序集中加载类是否会降低性能？
这是场景。我已经构建了一个用于执行存储过程的数据包装器类。我想在其他项目中使用这个类。众所周知，数据层代码通常必须尽快执行以避免瓶颈。
所以我的问题是，如果我要在自己的程序集中构建数据类，这样更容易分发到其他解决方案，这是否会对类本身造成任何加载时间损失？另一种选择是将类文件复制并粘贴到每个项目中。
Here is the scenario. I have built a data wrapper class for executing stored procedures. I would like to use this class in other projects. As we all know it is usually imperative that data layer code should execute as quickly as possible to avoid bottle-necking.
So my question is, If I were to build my data class in its own assembly which is easier to distribute to other solutions, does this create any sort of load time penalty for the class itself? The other alternative is to copy and paste the class files into each project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该注意，虽然加载程序集会产生非零（尽管可能微不足道）的成本，但在几乎所有情况下，每个 AppDomain 只发生一次，因此瓶颈不是问题。
You should note that while there is a non-zero (though likely trivial) cost associated with loading your assembly, in almost all cases it occurs only once per AppDomain, so bottle-necking is not a concern.
您意识到，整个框架也属于
其他程序集类别。我认为这里涉及的时间尺度并不重要，并且会影响您的流程。
You realise, the entire framework falls into the category
otherassemblies as well.I don't think the timescales involved here matter and will impact on your processes.
当您第一次需要来自另一个程序集的某种类型时，JIT 会加载类型。
它首先加载程序集本身，然后加载包含的所有类型。
之后，类型就在内存中，并且构造它们时不会有任何损失。
所有这些对于 AppDomain 来说都是正确的。但您可能只使用一个。
因此，您所指的性能问题只有在宠物组件加载后才会发生。
如果您担心这可能会在不应触发的情况下触发，您可以选择提前预加载所需的所有程序集 (链接到我的一个问题）。
Types are loaded by the JIT the first moment you require some type from another assembly.
It first loads the assembly itself then all types contained.
After that the types are in memory and there is no penalty in constructing them.
All this is true per AppDomain. But you are probably using only one.
So the performance issue you are referring to can happen only once pet assembly load.
If you are concerned this could be triggered when it should not, you can opt for preloading all the assemblies you need in advance (link to one question of mine).