ProfileOptimization实际起作用吗? [英] Does ProfileOptimization actually work?
问题描述
.NET 4.5的新性能增强之一是"MultiCode JIT"的引入.
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.
我感兴趣的原因是，如果没有NGEN，我的应用程序(IronScheme)将花费很长的启动时间，这意味着启动时会涉及大量的JIT'ng. (1.4秒vs NGEN时为0.1秒).
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).
我已经按照有关如何启用它的说明进行操作，并且可以看到已创建了一个小"(4-12KB).但是在随后的启动中，这似乎对缩短启动时间完全没有影响.仍然是1.4秒.
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).
我确实遇到的一个错误是SetProfileRoot似乎不理解/作为路径分隔符，请确保使用\.
One bug that I did encounter was that SetProfileRoot does not seem to understand a / as a path separator, make sure to use \ .
推荐答案
我们在Microsoft使用的经验法则是，Multicore JIT使您获得NGEN启动性能的一半.因此，如果您的应用在使用NGEN的情况下启动时间为0.1秒，而在不使用NGEN的情况下启动时间为1.4秒，那么我们预计多核JIT启动将花费大约0.75秒.
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.
话虽如此，我们必须设置一些限制，以确保无论有没有MCJ，程序的执行顺序都是相同的. MCJ有时会暂停后台线程，等待前台线程加载模块，如果出现程序集解析或模块解析事件，MCJ将中止后台编译.
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.
如果您想了解您所发生的情况，我们为MCJ功能提供了ETW(Windows事件跟踪)工具，我们将很快发布一个PerfView版本，如果您有需要，它将能够收集这些事件.跟踪您的应用启动情况.
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.
更新:PerfView已更新，可以显示后台JIT信息.以下是使用最新版本(1.2.2.0)诊断的步骤:
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):
- 使用PerfView主菜单中的Collect-> Run或Collect-> Collect，使用应用程序启动时的PerfView收集跟踪.
- 假设您使用收集"->运行"，将.exe的名称放在命令"文本框中，选择一个文件名(即IronScheme.etl)，从高级选项"中选择后台JIT"，然后单击运行命令".
- 关闭您的应用程序，然后双击生成的IronScheme.etl文件.
- 双击IronScheme.etl下列表中的"JIT Stats"视图，您应该在弹出的视图中看到以下内容:
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
您可以单击查看原始背景Jit诊断"以查看excel中的所有MCJ事件.我忘了问一个问题:您是在多核计算机还是多核VM上运行它?在只有一个逻辑处理器的VM中测试MCJ是一个常见的错误.
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屋！
