gpt4 book ai didi

c# - C# 编译器的图像调试选项如何影响 .NET JIT 编译性能(包括动态方法)?

转载 作者:可可西里 更新时间:2023-11-01 07:47:57 25 4
gpt4 key购买 nike

我正在尝试优化我的应用程序,使其在启动后立即运行良好。目前,它的发行版包含 304 个二进制文件(包括外部依赖项),总计 57 兆字节。它是一个 WPF 应用程序,主要执行数据库访问,没有任何重要的计算。

我发现调试配置为大多数操作提供了更好的(~5 倍增益)时间,因为它们是在应用程序进程的生命周期中首次执行的。例如,在 NGENed Debug 中打开应用内的特定屏幕需要 0.3 秒,JITted Debug 需要 0.5 秒,NGENed Release 需要 1.5 秒,JITted Release 需要 2.5 秒。

据我所知,JIT 编译时间的差距是由 JIT 编译器对发布二进制文件应用更积极的优化造成的。据我所知,调试和发布配置的不同之处在于 /p:DebugType。和 /p:Optimize传递给 C# 编译器的开关,但即使我使用 /p:Configuration=Release /p:DebugType=full /p:Optimize=false 构建应用程序,我也看到了相同的性能差距– 也就是说,与 /p:Configuration=Debug 中相同的图像调试选项.

我通过查看 DebuggableAttribute 确认应用了选项应用于生成的程序集。观察 NGEN 输出,我看到 <debug>添加到一些正在编译的程序集的名称中——NGEN 如何区分调试程序集和非调试程序集?正在测试的操作使用动态代码生成——什么级别的优化应用于动态代码?

注意:由于外部依赖,我使用的是 32 位框架。我应该在 x64 上期待不同的结果吗?

注意:我也不使用条件编译。因此两种配置的编译源是相同的。

最佳答案

如果如您所说,您有 304 个程序集要加载,那么这很可能是您的应用运行缓慢的原因。这似乎是要加载的程序集数量非常多。

每次 CLR 从尚未加载到 AppDomain 中的另一个程序集获取代码时,它必须从磁盘加载它。

您可能会考虑使用 ILMerge 来合并其中的一些程序集。这将减少从磁盘加载程序集的延迟(您预先使用一个更大的磁盘)。

这可能需要一些实验,因为并不是所有的东西都喜欢被合并(特别是那些使用反射,并且依赖于程序集文件名永不改变的)。它还可能导致非常大的组件。

关于c# - C# 编译器的图像调试选项如何影响 .NET JIT 编译性能(包括动态方法)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10170602/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com