EXE的大小会影响执行速度吗？
我将创建一些使用一些大型库 DLL 的命令行工具。出于安全原因，我计划将 DLL 嵌入到命令行的 EXE 中。
例子： 假设 CL（命令行工具）的功能只是将文件从 A 复制到 B。执行此操作的过程包含在 100MB 库 DLL 中。如果我只是从 DLL 中取出代码行并将它们粘贴到 CL 的代码中，那么 CL 将只有 10Kb。 但我不想这样做，所以我将完整的库嵌入到 CL 的 EXE 中，这将使其大小为 101MB。
请注意，以上只是一个示例。我曾经在某个地方（不记得在哪里）读到Windows只会使用EXE中实际使用的部分。因此，如果这是真的，那么 EXE 大小是 10Kb、100MB 还是 1GB 都没有关系。我不知道这是不是真的，所以才问这个问题。
我拥有 DLL 的代码，因此，如果最佳解决方案是不包含整个 DLL，而只是链接到或包含 CL 使用的 DLL 项目的那些代码文件，那么我会这样做。
那么问题是：10Kb CL 会比 101MB CL 运行得更快并且消耗更少的内存吗？
I'm going to create some command line tools that make use of some large library DLL's. For security reasons I plan to embed the DLL's in the command line's EXE.
Example:
Suppose the CL's (command line tool) functionality is to just copy a file from A to B. The procedure to do this is included in a 100MB library DLL. If I would just take out the lines of code from the DLL and paste them in the CL's code then the CL would only be 10Kb.
But I don't want to do that, so I embed the full library in the CL's EXE, which will make it 101MB in size.
Please be aware that the above is just an example. I once read somewhere (cannot remember where) that Windows would only use the part of the EXE that's actually used. So if that's true then it shouldn't matter if the EXE size is 10Kb, 100MB or 1GB. I don't know if that is true, so that's why I'm asking this question.
I own the code of the DLL, so if the best solution is to not include the whole DLL but just only link to or include those code files, of the DLL project, that are used by the CL then I will go that way.
So the question is: will the 10Kb CL run faster and consume less memory than the 101MB CL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，如果您出于安全原因将额外的 dll 嵌入到可执行文件中，那么就不要这样做。
如果该程序可以解压它，那么其他任何人都可以，所以如果您认为这会提高安全性，那么您只是在自欺欺人，除非您谈论的是工作安全。
其次，我怀疑这里的根本问题比其他人想象的更难回答。
如果您使用了常规的非托管可执行文件和非托管 dll，那么当您启动程序时，这些文件的部分内容将保留在内存空间中，但只有您使用的实际位才会映射到物理内存中。
换句话说，程序消耗的实际物理内存量在某种程度上与您使用的代码量以及代码的分布方式成正比。我说“某种程度上”是因为物理内存的分页是在页面的基础上完成的，并且页面具有固定的大小。因此，一个 100 字节的函数最终可能会将 8KB 页面中的 4KB（我不记得页面的大小）映射到内存中。如果您调用很多这样的函数，并且它们分布在代码的地址空间上，那么您最终可能会在大量物理内存中映射很少的代码。
当涉及到托管程序集时，情况会发生一些变化。托管代码不会以相同的方式直接映射到物理内存（注意，我对这里的细节很模糊，因为我不知道确切的细节），因为代码尚未准备好运行。在运行之前，必须对其进行 JIT 编译，并且 JITter 仅在需要进行 JIT 的基础上 JIT 代码。
换句话说，如果您在程序集中包含一个巨大的类，但从不使用它，它可能永远不会被 JITted，因此不会使用任何内存。
那么答案是否是“否”，因为它不会使用更多内存？
我不知道。我怀疑更大的程序集、更多的元数据放入反射表或诸如此类的东西会产生一些影响。
但是，如果您打算将其放入可执行文件中，则需要在加载之前将其解压到磁盘（这将“规避”您的“安全功能”），或者将其解压到内存中（这将需要所有这 100MB 的内存）。物理内存。）
因此，如果您担心使用大量内存，这是我的建议：
First of all, if you're embedding the extra dll into the executable for security reasons, then don't.
If the program can unpack it, anyone else cans, so you're only fooling yourself if you think this will improve security, unless it is job security you're talking about.
Secondly, I suspect the underlying question here is quite a bit harder to answer than others might think.
If you had used a regular non-managed executable and a non-managed dll, then portions of those files would be reserved in memory space when you start the program, but only the actual bits of it you use will be mapped into physical memory.
In other words, the actual amount of physical memory the program would consume would be somewhat proportional to the amount of code you use from them and how that code is spread out. I say "somewhat" because paging into physical memory is done on a page basis, and pages have a fixed size. So a 100 byte function might end up mapping a 4KB of 8KB page (I don't recall the sizes of the pages any more) into memory. If you call a lot of such functions, and they're spread out over the address space of the code, you might end up mapping in a lot of physical memory for little code.
When it comes to managed assemblies, the picture changes somewhat. Managed code isn't mapped directly into physical memory the same way (note, I'm fuzzy on the details here because I don't know the exact details) because the code is not ready to run. Before it can be run it has to be JITted, and the JITter only JITs code on a need-to-jit basis.
In other words, if you include a humongous class in the assembly, but never use it, it might never end up being JITted and thus not use any memory.
So is the answer "no", as in it won't use more memory?
I have no idea. I suspect that there will be some effect of a larger assembly, more metadata to put into reflection tables or whatnot.
However, if you intend to place it into the executable, you either need to unpack it to disk before loading it (which would "circumvent" your "security features"), or unpack it into memory (which would require all of those 100MB of physical memory.)
So if you're concerned about using a lot of memory, here's my advice:
较小的运行速度会更快并且消耗更少的内存吗？是的。
这足以带来改变吗？谁知道？如果做错了，大的可能会多占用大约 100MB 的内存（三个猜测我从哪里得到这么多内存）
但是包含 100MB 不需要的“东西”确实看起来非常愚蠢......
编辑：我的“是的” ” 此处顶部应加上“无穷小如此”，顺便说一句也是如此。请参阅下面的评论。
Will the smaller one run faster and consume less memory? Yes.
Will it be enough to make a difference? Who knows? If done wrong, the big one might take up about 100MB more memory (three guesses where I got that amount from)
But it sure seems awfully silly to include 100MB of 'stuff' that isn't needed...
EDIT: My "Yes" at the top here should be qualified with "infinitesimally so", and incidentally so. See comments, below.