程序集中的类数量如何影响性能? [英] How does the number of classes in an assembly impact performance?

问题描述

我正在从事的项目将为大量类生成代码 - 预计会有数百到数千个.在生成时不知道这些类中有多少将被实际访问.

The project I'm working on will generate code for a large number of classes - hundreds to thousands is expected. It is not known at generation time how many of these classes will actually be accessed.

生成的类可以 (1) 全部存在于单个程序集(或可能是少数程序集)中，这些程序集将在脚趾消耗过程开始时加载.

The generated classes could (1) all live in a single assembly (or possibly a handful of assemblies), which would be loaded when toe consuming process starts.

...或 (2) 我可以为 每个 类生成一个程序集，就像 Java 将每个类编译为一个 *.class 二进制文件一样，并且然后提出一种机制来按需加载程序集.

...or (2) I could generate a single assembly for each class, much like Java compiles every class to a single *.class binary file, and then come up with a mechanism to load the assemblies on demand.

问题:哪种情况会产生更好的(内存和时间)性能?

The question: which case would yield better (memory and time) performance?

我的直觉是，对于情况 (1)，加载时间和使用的内存与构成单个整体程序集的类的数量成正比.OTOH，案例 (2) 带来了并发症.

My gut feeling is that for case (1) the load time and used memory are directly proportional to the number of classes that make up the single monolithic assembly. OTOH, case (2) comes with its complications.

如果您知道与加载程序集内部相关的任何资源，尤其是调用了哪些代码(如果有！?)以及分配了哪些内存(新加载程序集的簿记)，请分享.

If you know any resources pertaining to the internals of loading assemblies, especially what code gets called (if any!?) and what memory is allocated (book-keeping for the newly loaded assembly), please share them.

推荐答案

您正在尝试解决一个不存在的问题，程序集加载在 .NET 中非常 进行了大量优化.

You are trying to solve a non-existing problem, assembly loading is very heavily optimized in .NET.

将一个大型组件分解成许多较小的组件无疑是您能做的最糟糕的事情.到目前为止，加载程序集的最大开销是查找文件.这是一个冷启动问题，CLR 加载器被慢速磁盘卡住，需要检索和搜索目录条目以定位包含文件内容的磁盘扇区.当可以从文件系统缓存中检索程序集数据时，这个问题在热启动后就会消失.请注意，Java 也不会这样做，它会将 .class 文件打包到 .jar 中..jar 大致相当于一个程序集.

Breaking up a large assembly into many smaller ones is without a doubt the very worst thing you can do. By far the biggest expense in loading an assembly is finding the file. This is a cold start problem, the CLR loader is bogged down by the slow disk, directory entries need to be retrieved and searched to locate the disk sectors that contain the file content. This problem disappears on a warm start when the assembly data can be retrieved from the file system cache. Note that Java doesn't do it it this way either, it packages .class files into a .jar. A .jar is the rough equivalent of an assembly.

一旦找到文件，.NET 就会使用操作系统工具使实际加载程序集数据的成本非常低.它使用内存映射文件.这仅涉及为文件保留虚拟内存，但不从文件中读取.

Once the file is located, .NET uses an operating system facility to making actually loading the assembly data very cheap. It uses a memory mapped file. Which involves merely reserving the virtual memory for the file but not reading from the file.

读取直到稍后才会发生，并且是由页面错误完成的.任何按需分页虚拟内存操作系统的功能.访问虚拟内存会产生页面错误，操作系统从文件中加载数据并将虚拟内存页面映射到 RAM.之后程序继续运行，永远不会意识到它被操作系统中断了.抖动将产生这些页面错误，它访问程序集中的元数据表以定位方法的 IL.然后从中生成可执行的机器代码.

Reading doesn't happen until later and is done by a page fault. A feature of any demand-paged virtual memory operating system. Accessing the virtual memory produces a page fault, the operating system loads the data from the file and maps the virtual memory page into RAM. After which the program continues, never being aware that it got interrupted by the OS. It will be the jitter that produces these page faults, it accesses the metadata tables in the assembly to locate the IL for a method. From which it then generates executable machine code.

此方案的一个自动好处是，您无需为程序集中但未使用的代码付费.抖动根本没有理由查看包含 IL 的文件部分，因此它实际上从未被读取.

An automatic benefit from this scheme is that you never pay for code that is in an assembly but is not being used. The jitter simply has no reason to look at the section of the file that contains the IL so it never actually gets read.

并注意这个方案的缺点，第一次使用一个类确实涉及由于磁盘读取而导致的性能命中.这需要以一种或另一种方式支付，在 .NET 中，债务是在最后一刻到期的.这就是为什么属性以缓慢而著称.

And note the disadvantage of this scheme, using a class for the first time does involve a perf hit due to the disk read. This needs to be paid for one way or another, in .NET the debt is due at the last possible moment. Which is why attributes have a reputation for being slow.

较大的组件总是比许多较小的组件好.

Bigger assemblies are always better than many smaller assemblies.

这篇关于程序集中的类数量如何影响性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！