如何在 NGen 之前衡量正确重新调整 .NET 程序集基准的效果？
我们的应用程序有很多 .NET 程序集，到目前为止，这些程序集尚未使用 NGen 脚本进行部署，因此它们始终在运行时进行 JIT 处理。
由于我们的应用程序通常部署到终端服务器，因此让 Windows 共享代码的二进制映像可能比当前方式更优化，因此我正在考虑设置基地址并对程序集进行 NGen 处理。
因此，我在没有 NGen 的情况下运行了该程序，并使用 [SysInternals 中的 listdlls][1] 来查找每个文件的大小，然后将其增加到下一类大小（即 xxxx --> 10000）。然后，我为所有程序集列出了一个内存列表，并调整了它们的基地址。
到目前为止一切顺利，通过 listdlls 我现在可以看到我们的程序集都没有在运行时被重新设置。
但是，如何测量两个实例之间实际共享的内存量？基本上，假设我在没有对程序集执行 NGEN 的情况下启动了程序的两个实例，然后在执行 NGEN 后再次执行。
我应该查看什么样的数字以及使用哪个工具才能找到实际效果（如果有）？
例如，我知道这样一个事实：对程序集进行变基的行为可能会移动我们使用的第 3 方程序集（例如 DevExpress 组件），以便它们突然必须变基，然后整个事情就变成了一场清洗。
那么，我从哪里读取哪些数字呢？比如，我是否使用任务管理器的工作集？私人记忆？提交大小？释放内存之前和之后？
有什么建议吗？
Our application has a lot of .NET assemblies, which up until now, has not been deployed with NGen-scripts, so they are always JITted at runtime.
Since our application is typically deployed to a terminal server, getting Windows to share binary images of the code is probably more optimal than the current way, so I'm looking at setting base addresses and NGen'ning the assemblies.
So I ran the program without NGen whatsoever, and used [listdlls from SysInternals][1] to find the size of each, which I then increased to the next class of size (ie. xxxx --> 10000). I then laid out a memory list for all our assemblies, and adjusted the base addresses of them all.
So far so good, with listdlls I can now see that none of our assemblies are rebased at runtime.
However, how can I measure how much memory is actually shared between two instances? Basically, let's say I start two instances of the program without having executed NGEN on the assemblies, and then after having executed NGEN, do it again.
What kind of numbers should I look at, and from which tool, in order to find the actual effect, if any?
For instance, I'm aware of the fact that the very act of rebasing our assemblies might move 3rd party assemblies we use (DevExpress components for instance) around so that they suddenly must rebase, and then the whole thing is a wash.
So, from where do I read which numbers? Like, do I use the working set of task manager? The private memory? commit size? free memory before and after?
Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对您来说唯一有意义的值是进程的私有字节数，它是分配的字节数（无论在哪里），并且进程之间不可共享。
我找不到来源，但目前的 .Net 也可以共享（某些）程序集而无需 ngend。
编辑：我也对您关于有或没有 ngening 的私有字节变化的发现感兴趣。
The only meaningful value for you will be Private Bytes of a process which is the number of bytes allocated (regardless of where) that are not shareable between processes.
I can't find a source but afair current .Net can also share (some) assemblies without being ngend.
Edit: I would also be interested in your findings about the change of private bytes with and without ngening.
实际上，不再需要在 Vista 或更高版本上重新建立基础。请参阅我对另一篇文章的回答，其中引用了此 Microsoft 博客。该博客解释说，“使用 ASLR，虽然每台机器的最终位置是随机的，但对于机器上的每个进程来说都是相同的，这意味着重新定位的数据可以在所有进程之间共享。”
整个变基过程有点做作，所以这是个好消息！
Actually, it's no longer necessary to rebase on Vista or later. See my answer to another post which refers to this Microsoft blog. The blog explains, "with ASLR, while the final location is random per machine, it is the same for each process on the machine, which means the relocated data can be shared across all processes."
The whole process of rebasing is a bit hokey, so this is welcome news!