ProfileOptimization 真的有效吗? [英] Does ProfileOptimization actually work?

问题描述

.NET 4.5 的新性能增强之一是引入了MultiCode JIT".

有关详细信息，请参阅此处.

我已经试过了，但似乎对我的申请没有影响.

我感兴趣的原因是我的应用程序 (IronScheme) 需要很长时间才能启动，如果没有 NGEN'd，这意味着启动时涉及相当多的 JIT'ng.(1.4 秒 vs 0.1 秒，当 NGEN'd 时).

我已按照有关如何启用此功能的说明进行操作，我可以看到创建了一个小"(4-12KB).但是在后续的启动中，对于提高启动时间似乎完全没有效果.仍然是 1.4 秒.

有没有人在实践中真正见过(或制作)了这项工作?

此外，对跟踪"哪些代码有任何限制吗?例如:程序集加载上下文、瞬态程序集等.我问这个是因为创建的文件似乎永远不会增长，但实际上我生成了相当数量的代码(在瞬态程序集中).

我遇到的一个错误是 SetProfileRoot 似乎不理解/作为路径分隔符，请确保使用 .

解决方案

我们在 Microsoft 使用的经验法则是多核 JIT 可以让您实现 NGEN 启动性能的一半.因此，如果您的应用在使用 NGEN 的情况下在 0.1 秒内启动，在没有 NGEN 的情况下启动 1.4 秒，我们预计多核 JIT 启动需要大约 0.75 秒.

话虽如此，我们不得不设置一些限制以保证程序执行顺序在有和没有 MCJ 的情况下是相同的.MCJ 有时会暂停后台线程等待前台线程加载模块，如果有程序集解析或模块解析事件，则会中止后台编译.

如果您想了解您的情况发生了什么，我们有 ETW(Windows 事件跟踪)检测 MCJ 功能，我们将很快发布 PerfView 版本，如果您跟踪您的应用启动情况.

更新:PerfView 已更新，可以显示后台 JIT 信息.以下是使用最新版本 (1.2.2.0) 进行诊断的步骤:

1. 使用 PerfView 收集应用程序启动的跟踪信息，可以使用从 PerfView 主菜单中的收集->运行或收集->收集.
2. 假设您使用了收集"->运行"，将 .exe 的名称放在命令"文本框中，选择一个文件名(即 IronScheme.etl)，从高级选项"中选择后台 JIT"，然后单击运行命令".
3. 关闭您的应用程序并双击生成的 IronScheme.etl 文件.
4. 双击 IronScheme.etl 下方列表中的 JIT Stats 视图，您应该会在弹出的视图中看到如下内容:

<块引用>

这个过程使用了后台JIT编译(System.Runtime.ProfileOptimize)方法背景 JITTed : 2,951百分比 # 方法背景 JITTed : 52.9%MSec 背景 JITting : 3,901JITting 是背景的时间百分比:50.9%后台 JIT 线程:11308

您可以单击查看原始背景 Jit 诊断"以查看 excel 中的所有 MCJ 事件.我忘了问一个问题:你是在多核机器还是多核 VM 上运行它?在只有一个逻辑处理器的 VM 中测试 MCJ 是一个常见的错误.

One of the new performance enhanchements for .NET 4.5 is the introduction of the 'MultiCode JIT'.

See here for more details.

I have tried this, but it seems to have no effect on my application.

The reason why I am interested is that my app (IronScheme) takes a good long time to startup if not NGEN'd, which implies a fair amount of JIT'ng is involved at startup. (1.4 sec vs 0.1 sec when NGEN'd).

I have followed the instructions on how to enable this, and I can see a 'small' (4-12KB) is created. But on subsequent startup, it seems to have absolutely no effect on improving the startup time. It is still 1.4 sec.

Has anyone actually seen (or made) this work in practice?

Also, are there any limitations on which code will be 'tracked'? Eg: assembly loading contexts, transient assemblies, etc. I ask this as the created file never seems to grow, but I am in fact generating a fair amount of code (in a transient assembly).

One bug that I did encounter was that SetProfileRoot does not seem to understand a / as a path separator, make sure to use .

解决方案

The rule of thumb we use at Microsoft is that Multicore JIT gets you about half way towards NGEN startup performance. Thus if your app starts in 0.1 seconds with NGEN and 1.4 seconds without NGEN, we would expect Multicore JIT startup to take about 0.75 seconds.

That being said, we had to put some limitations in place to guarantee that program execution order is the same with and without MCJ. MCJ will sometimes pause the background thread waiting for modules to be loaded by the foreground thread, and will abort background compilation if there is an assembly resolve or module resolve event.

If you want to find out what's happening in your case, we have ETW (Event Tracing For Windows) instrumentation of the MCJ feature and we will be releasing a version of PerfView soon which will be able to collect these events by if you take a trace of your app startup.

Update: PerfView has been updated to be able to show background JIT information. Here are the steps to diagnosing with the latest version (1.2.2.0):

1. Collect a trace using PerfView of your application startup, either using Collect->Run or Collect->Collect from the main PerfView menu.
2. Assuming you used Collect-> Run, put the name of your .exe in the Command text box, pick a filename (i.e. IronScheme.etl), select Background JIT from Advanced Options, and click Run Command.
3. Close your application and double click on the IronScheme.etl file that gets generated.
4. Double click on the JIT Stats view in the list underneath IronScheme.etl, you should see something like this in the view that pops up:

This process uses Background JIT compilation (System.Runtime.ProfileOptimize) 
    Methods Background JITTed : 2,951 
    Percent # Methods Background JITTed : 52.9% 
    MSec Background JITTing : 3,901 
    Percent Time JITTing is Background : 50.9% 
    Background JIT Thread : 11308 

You can click on "View Raw Background Jit Diagnostics" to see all of the MCJ events in excel. One question I forgot to ask: are you running this on a multicore machine or multicore VM? It is a common mistake to test out MCJ in a VM that only has a single logical processor.

这篇关于ProfileOptimization 真的有效吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！