加载许多托管 DLL 而不使用其中的任何类型是不是很糟糕？
背景：在我的公司，我们正在开发一堆使用相同核心 dll 的应用程序。 这些 dll 使用 Spring.net 的 IoC 容器来连接（自动连接）。 所有应用程序都使用相同的 spring 配置文件，并且该配置文件指向许多不同 dll 中的许多类。 但并非所有应用程序都需要每个 dll 的功能。 但由于 IoC 容器的工作方式，Spring.net 会加载所有 dll，以检查类型并检查它们实现的接口等。
核心问题：我知道最好只加载你真正使用的dll。 但是仅仅加载托管 dll 真的会对内存使用产生不良影响吗？ 或者是先使用 dll 中的类，然后对它们进行 JIT 处理以使用最多的内存？
Background: At my company we are developing a bunch applications that are using the same core dll's. These dll's are using Spring.net's IoC-container to wire things up (auto-wiring). All applications are using the same spring configuration file, and this configuration file points to many classes in many different dll's. But not all application needs functionality from every dll. But because of the way IoC-containers works, all dll's is loaded for Spring.net to examine the types and check what interfaces they implement and so on.
Core question: I understand that it's better to just load the dll's you really use. But is it really bad for memory usage just to load a managed dll? Or is it first then you are using classes in the dll and they are getting JIT'ed that the most memory are used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
真正糟糕是一个很难量化的术语，我想这取决于事物的规模，一般来说，我会说，如果您可以避免加载不需要的东西，那么您应该这样做。 但当然，如果您使用反射来确定是否可以使用它，那么您首先必须加载它……先有鸡还是先有蛋的问题。
但需要注意的是，一旦将程序集加载到应用程序域中，您就无法从该应用程序域中卸载它，但是可以动态创建应用程序域，将程序集加载到其中并在您卸载时卸载整个应用程序域。完毕。
Really bad is a difficult term to quantify, I guess depends on the scale of things, in general I'd say that if you can avoid loading stuff you don't need then you should. But of course if you are using reflection to determine if you can use it, you first have to load it...chicken and the egg problem.
Something to be aware of though, once you load an assembly into an Application Domain you can't then unload it from that App domain, it is possible however to dynamically create app domains load assemblies into it and unload the whole app domain when you are done.
当然，由于从磁盘读取程序集和证据/安全检查，加载 dll 而不使用它们会导致启动时间变慢。 但是，如果内存是您关心的问题，那么您至少可以确定，如果您确实不使用其中的任何类型，则不会浪费比程序集大小更多的内存。 当然，如果在 spring 配置中指定了这些类型，那么至少这些类型会被加载到内存中，并且它们的静态初始化程序（如果有）将被执行。 在极少数情况下，这可能是一个问题。 JITing 是由 CLR 在每个方法的基础上完成的，因此您不使用的方法不会浪费 cpu+内存。
在任何情况下，您都可以将配置文件拆分为多个分区，例如，将模块 A 的所有对象定义放入文件 moduleA.config，将模块 B 的所有定义放入文件 moduleB.config，并仅指定特定应用程序真正需要的那些模块。
哈，
Erich
P.S.：我还想建议您将 Spring for .NET 相关问题发布到我们的社区论坛 -您的问题更有可能在那里得到解答。
of course loading dll's w/o using them causes slower startup time due to reading the assembly from disk and evidence/security checks. But if memory is your concern you at least can be sure, you won't waste more memory than the size of your assemblies if you really don't use any types within. Of course if those types are specified in the spring configuration, at least those types get loaded into memory and their static initializer (if any) will be executed. In rare cases this might be an issue. JITing is done on by the CLR on a per-method basis, so methods you do not use won't waste cpu+memory.
In any case you may split your configuration files into partitions e.g. by putting all object definitions of module A into file moduleA.config, all definitions of module B into file moduleB.config and specify only those modules for your particular application that are really needed.
hth,
Erich
P.S.: I'd also like to suggest you post Spring for .NET relevant questions to our community forums - it is more likely to get your questions answered there.
我不认为这有多糟糕。 唯一的问题是，由于您的应用程序占用大量元数据和内存量，正在使用的应用程序的某些部分更有可能位于不同的内存页面，这可能会导致一些性能泄漏，但它是应用程序的非常低的部分，其中这类事情很关键。
I don't think it's so bad. Only problem is that because of large metadata and amount of memory your application takes it's more possible that some parts of application which are in use will be located at different memory pages which can 'cause some performance leaks, but it's very low segment of application where this type of things are critical.
如果从未使用过程序集中的任何代码，则最终该程序集中的页面将从内存移至页面文件中，以支持主动使用的页面。 在这种情况下，总体长期影响可能很小。 尽管如此，这会对启动时间产生负面影响。
If none of the code from the assembly is ever used, then eventually the pages from that assembly will be moved from memory into the page file in favour of actively used pages. In which case, the overall long-term effect is likely to be minor. Although, there will be a negative effect on startup time.