DLR 的内存占用是多少?

发布于 2024-10-20 07:23:57 字数 477 浏览 3 评论 0原文

我正在考虑有限地使用 C# 的 dynamic 关键字。我的最初的计时试验令人惊讶 - 性能受到影响100,000 次迭代不到一秒(可能是由于 DLR 缓存)。

不过,我无法访问内存分析器,并且 Eric Lippert写道:

然后启动 DLR [...] DLR 然后启动一个特殊版本 C# 编译器...

它的内存占用是多少?当动态代码被垃圾收集时它是否会被卸载?

I'm considering making limited use of C#'s dynamic keyword. My initial time trials were astonishing - a performance hit of less than a second for 100,000 iterations (likely due to DLR caching).

I don't have access to a memory profiler, though, and Eric Lippert wrote:

Then it starts up the DLR [...] The DLR
then starts up a special version of
the C# compiler...

What's the memory footprint of this, and is it unloaded when the dynamic code is garbage-collected?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

此生挚爱伱 2024-10-27 07:23:57

动态代码被垃圾回收时是否被卸载?

这个问题预设了一个不正确的前提;在当前实现中,动态生成的代码不会被垃圾收集。它被缓存并且缓存一直存在,直到应用程序域被拆除。我们不知道最后一次调用特定代码路径的时间是什么时候。

如果您想了解对虚拟内存、堆内存、私有字节、共享字节等的影响,那么我的建议是您使用内存分析器来回答这些具体问题。您可能会对六种不同的“内存足迹”感兴趣,但我不知道哪一种与您相关。使用适当的工具来衡量您感兴趣的内容,然后您就会知道。

is it unloaded when the dynamic code is garbage-collected?

The question presupposes an incorrect premise; the dynamically generated code isn't garbage collected in the current implementation. It is cached and the caches live until the appdomain is torn down. We don't know when the last time a particular code path is going to be called.

If you want to know the impact on virtual memory, heap memory, private bytes, shared bytes, and so on, then my suggestion is that you use a memory profiler to answer those specific questions. There are a half a dozen different "memory footprints" you could be interested in, and I don't know which one is relevant to you. Use the appropriate tool to measure whatever is interesting to you, and then you'll know.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文