");
writer.Write("| Start (msec) | JitTimemsec | IL Size | Native Size | Method Name | " +
- "BG | Module | ");
+ "Trigger | Module | ");
if (backgroundJitEnabled)
{
writer.Write("Distance Ahead | Background JIT Blocking Reason | ");
@@ -170,12 +220,12 @@ public static void ToHtml(TextWriter writer, TraceProcess stats, TraceLoadedDotN
foreach (TraceJittedMethod _event in runtime.JIT.Methods)
{
writer.Write("
|---|
| {0:n3} | {1:n1} | {2:n0} | {3:n0} | {4} | {5} | {6} | ",
- _event.StartTimeMSec, _event.CompileCpuTimeMSec, _event.ILSize, _event.NativeSize, _event.MethodName ?? " ", (_event.IsBackGround ? "BG" : "JIT"),
+ _event.StartTimeMSec, _event.CompileCpuTimeMSec, _event.ILSize, _event.NativeSize, _event.MethodName ?? " ", GetShortNameForThreadClassification(_event.CompilationThreadKind),
_event.ModuleILPath.Length != 0 ? Path.GetFileName(_event.ModuleILPath) : "<UNKNOWN>");
if (backgroundJitEnabled)
{
writer.Write("{0:n3} | {1} | ",
- _event.DistanceAhead, _event.IsBackGround ? "Not blocked" : _event.BlockedReason);
+ _event.DistanceAhead, _event.CompilationThreadKind == CompilationThreadKind.MulticoreJitBackground ? "Not blocked" : _event.BlockedReason);
}
writer.WriteLine("
");
eventCount++;
@@ -214,19 +264,72 @@ public static void ToHtml(TextWriter writer, TraceProcess stats, TraceLoadedDotN
writer.WriteLine("
");
}
+ private static string FormatThreadingModelTableRow(CompilationThreadKind kind, long count, double jitTimeMsec, TraceProcess stats, TraceLoadedDotNetRuntime runtime)
+ {
+ return FormatThreadingModelTableRow(GetLongNameForThreadClassification(kind), count, jitTimeMsec, stats, runtime);
+ }
+
+ private static string FormatThreadingModelTableRow(string name, long count, double jitTimeMsec, TraceProcess stats, TraceLoadedDotNetRuntime runtime)
+ {
+ var countPercent = runtime.JIT.Stats().Count == 0 ? "-" : (count * 100.0 / runtime.JIT.Stats().Count).ToString("N1");
+ var cpuPercent = stats.CPUMSec == 0 ? "-" : (jitTimeMsec * 100.0 / stats.CPUMSec).ToString("N1");
+ return string.Format("| {0} | {1} | {2} | {3:F1} | {4} |
",
+ name, count, countPercent, jitTimeMsec, cpuPercent);
+ }
+
+ static string GetShortNameForThreadClassification(CompilationThreadKind kind)
+ {
+ if(kind == CompilationThreadKind.Foreground)
+ {
+ return "FG";
+ }
+ else if(kind == CompilationThreadKind.MulticoreJitBackground)
+ {
+ return "MC";
+ }
+ else if(kind == CompilationThreadKind.TieredCompilationBackground)
+ {
+ return "TC";
+ }
+ else
+ {
+ throw new ArgumentException("Unknown CompilationThreadKind: " + kind);
+ }
+ }
+
+ static string GetLongNameForThreadClassification(CompilationThreadKind kind)
+ {
+ if (kind == CompilationThreadKind.Foreground)
+ {
+ return "Foreground";
+ }
+ else if (kind == CompilationThreadKind.MulticoreJitBackground)
+ {
+ return "Multicore JIT Background";
+ }
+ else if (kind == CompilationThreadKind.TieredCompilationBackground)
+ {
+ return "Tiered Compilation Background";
+ }
+ else
+ {
+ throw new ArgumentException("Unknown CompilationThreadKind: " + kind);
+ }
+ }
+
public static void ToCsv(string filePath, TraceLoadedDotNetRuntime runtime)
{
var listSeparator = Thread.CurrentThread.CurrentCulture.TextInfo.ListSeparator;
using (var writer = File.CreateText(filePath))
{
- writer.WriteLine("Start MSec{0}JitTime MSec{0}ThreadID{0}IL Size{0}Native Size{0}MethodName{0}BG{0}Module{0}DistanceAhead{0}BlockedReason", listSeparator);
+ writer.WriteLine("Start MSec{0}JitTime MSec{0}ThreadID{0}IL Size{0}Native Size{0}MethodName{0}Trigger{0}Module{0}DistanceAhead{0}BlockedReason", listSeparator);
for (int i = 0; i < runtime.JIT.Methods.Count; i++)
{
var _event = runtime.JIT.Methods[i];
var csvMethodName = _event.MethodName.Replace(",", " "); // Insure there are no , in the name
writer.WriteLine("{1:f3}{0}{2:f3}{0}{3}{0}{4}{0}{5}{0}{6}{0}{7}{0}{8}{0}{9}{0}{10}", listSeparator,
_event.StartTimeMSec, _event.CompileCpuTimeMSec, _event.ThreadID, _event.ILSize,
- _event.NativeSize, csvMethodName, (_event.IsBackGround ? "BG" : "JIT"), _event.ModuleILPath, _event.DistanceAhead, _event.BlockedReason);
+ _event.NativeSize, csvMethodName, GetShortNameForThreadClassification(_event.CompilationThreadKind), _event.ModuleILPath, _event.DistanceAhead, _event.BlockedReason);
}
}
}
@@ -369,15 +472,7 @@ public static JITStatsEx Create(TraceLoadedDotNetRuntime mang)
stats.TotalBGJITStats = new JITStats();
foreach (TraceJittedMethod _method in mang.JIT.Methods)
{
- if (_method.ThreadID == mang.JIT.Stats().BackgroundJitThread)
- {
- _method.IsBackGround = true;
- // update stats
- stats.TotalBGJITStats.Count++;
- stats.TotalBGJITStats.TotalCpuTimeMSec += _method.CompileCpuTimeMSec;
- stats.TotalBGJITStats.TotalILSize += _method.ILSize;
- stats.TotalBGJITStats.TotalNativeSize += _method.NativeSize;
- }
+ stats.TotalBGJITStats.AddMethodToStatistics(_method);
}
}
@@ -387,12 +482,12 @@ public static JITStatsEx Create(TraceLoadedDotNetRuntime mang)
{
if (_method.ModuleILPath != null)
{
- if (!stats.TotalModuleStats.ContainsKey(_method.ModuleILPath)) stats.TotalModuleStats.Add(_method.ModuleILPath, new JITStats());
- // update stats
- stats.TotalModuleStats[_method.ModuleILPath].Count++;
- stats.TotalModuleStats[_method.ModuleILPath].TotalCpuTimeMSec += _method.CompileCpuTimeMSec;
- stats.TotalModuleStats[_method.ModuleILPath].TotalILSize += _method.ILSize;
- stats.TotalModuleStats[_method.ModuleILPath].TotalNativeSize += _method.NativeSize;
+ if (!stats.TotalModuleStats.ContainsKey(_method.ModuleILPath))
+ {
+ stats.TotalModuleStats.Add(_method.ModuleILPath, new JITStats());
+ }
+ JITStats moduleStats = stats.TotalModuleStats[_method.ModuleILPath];
+ moduleStats.AddMethodToStatistics(_method);
}
}
diff --git a/src/PerfView/SupportFiles/HtmlReportUsersGuide.htm b/src/PerfView/SupportFiles/HtmlReportUsersGuide.htm
index f14fc18dd..1e60c8654 100644
--- a/src/PerfView/SupportFiles/HtmlReportUsersGuide.htm
+++ b/src/PerfView/SupportFiles/HtmlReportUsersGuide.htm
@@ -62,16 +62,51 @@
- PerfView tracks detailed information of what methods
- were Just In Time compiled. This data is mostly useful for
- optimizing startup (because that is when most methods get JIT compiled).
- If large numbers of methods are being compiled it can noticeably affect startup
- time. This report tells you exactly how much time is being spent (in fact
- exactly which methods and exactly when they were compiled). If JIT
- time is high, the
- NGen
- Tool can be used to precompile the code, and thus eliminate most of this
- overhead at startup.
+ PerfView tracks detailed information of what methods were Just In Time compiled.
+ This data is mostly useful for optimizing startup (because that is when most
+ methods get JIT compiled). If large numbers of methods are being compiled it
+ can noticeably affect startup time. This report tells you why the JIT was
+ invoked and exactly how much time is being spent on each compilation.
+
+ The summary statistics show JIT time broken down by the three different ways the
+ JIT can be triggered. First, foreground jitting occurs when a thread running managed
+ code wants to invoke a particular method that has not yet been compiled, in which
+ case the JIT is invoked synchronously to produce the code. Second, background
+ jitting occurs when the runtime predicts a method will be invoked in the future
+ and then pre-emptively invokes the JIT to compile it on a background thread. These
+ compilations occur in parallel with compilations on the foreground thread and
+ thus reduce total startup time. Third, tiered compilation is a feature that compiles
+ code a second time to generate higher quality code for frequently used methods.
+ Most tiered compilation JIT activity should not occur right at startup, but
+ rather very shortly afterwards. The JIT time used for tiered compilation determines
+ how quickly after startup the application transitions from running at a modest
+ speed to running at an optimal steady-state speed.
+
+ If there is a large amount of time spent in the sum of Foreground and Multicore JIT
+ Background compilations then this can cause the application to start slowly. There
+ are several techniques to improve the startup performance.
+
+ -
+ Precompile the code - On Desktop .NET the
+
+ NGen Tool
+ can be used. On .Net Core
+
+ Crossgen
+ can be used instead. Note that the ReadyToRun format produced by the crossgen tool
+ does not handle compiling generic code over value types so the number of compilations
+ at runtime will decrease substantially but it will often not go to zero.
+
+ -
+ Use Background jitting
+
+ -
+ On .Net Core 2.1 and above use Tiered compilation
+
+ -
+ Attempt to restructure your code so that less of it is invoked in the startup path.
+
+
As an additional option enabled with the JITInlining feature, PerfView can track
all of the decisions made by the JIT about whether to inline or not at every call site.
@@ -85,11 +120,16 @@
Background JIT compilation is a feature that was introduced in Version 4.5 of the .NET runtime. The basic idea is to take advantage of multiple processors available on most machines to speed up startup time by doing Just in Time (JIT) compilation on a background thread. Note that the .NET runtime's preferred solution to the cost o JIT compilation is to precompile the code with NGEN. This reduces the cost of JIT compilation to 0, where background JIT compilation cannot do nearly as well (it tends to reduce it by half), so using NGEN as part of application deployment should be considered first. However if using the
- NGen
- Tool is impossible (XCOPY deployment, non-admin deployment, silverlight, IL code generated at runtime), background JIT is the next best option.
+
+
+ Background JIT compilation is a feature that was introduced in Version 4.5 of the .NET runtime. The basic idea is to take advantage of multiple processors available on most machines to speed up startup time by doing Just in Time (JIT) compilation on a background thread. Note that the .NET runtime's preferred solution to the cost o JIT compilation is to precompile the code with NGEN. This reduces the cost of JIT compilation to 0, where background JIT compilation cannot do nearly as well (it tends to reduce it by half), so using NGEN as part of application deployment should be considered first. However if using the
+
+ NGen
+ Tool
+ is impossible (XCOPY deployment, non-admin deployment, silverlight, IL code generated at runtime), background JIT is the next best option.
+
There is a fundamental problem trying to push JIT compilation onto background threads, namely that the set of methods you will want to JIT compile depends on program execution and is not known until just before the method is used. Thus to take advantage of multiple processors you need 'oracle' that will tell you the methods you need to compile well before you will actually need to execute them.
The solution that the runtime uses is to rely on PREVIOUS runs of the same program to act as this oracle that will predict the methods that need to be compiled. For this to work the runtime will need to store on disk information about what methods were JIT compiled on the last run. Moreover, you really don't want the COMPLETE list of methods compiled because that list will include methods use well after startup and cause you to JIT compile things that are not that important. Thus to make background JIT compilation work well, we need help from the application. This is exposed in two new methods of the System.Runtime.ProfilerOptimization class introduced in .NET Version 4.5
@@ -120,30 +160,56 @@ Expected Win from Background JIT Compilation
Viewing Background JIT Compilation events.
If you have activated background JIT by placing the SetProfileRoot and StartProfile calls into your program you can view its effectiveness by turning on special background JIT compilation events. You do this by checking the 'Background JIT' checkbox on the advanced options of the 'Collection' dialog box. When you do this, the JITStats report is enhanced in several ways for processes that have called SetProfileRoot and StartProfile.
- - For that process, a set of top level statistics are displayed indicating how many JIT compilations happened in the background. The most important of these metrics is the 'JIT time NOT moved to background thread'. This is the JIT time that matters because it is left on the foreground thread where it slows down the application. The difference between this number and the JIT time on a run without background JIT is the 'win' of performing this optimization.
+ - Each process has a set of top level statistics indicating how many JIT compilations happened in the foreground and background. Any JIT time that remains on the foreground thread slows down the application startup. The difference between the foreground times on runs with and without background JIT is the 'win' of performing this optimization.
- There is a hyperlink to the a CSV spreadsheet displaying detailed diagnostics of the what was JIT compiled in the background as well as what was recorded for the next launch of the program.
- - The 'BG' column of each JIT compiled method is set to indicate whether the JIT compilation happened in the background or not.
+ - The 'Trigger' column of each method indicates whether the compilation happened in the foreground.
What can go wrong with background JIT compilation.
- It your program has used SetProfileRoot and StartProfile, but JIT compilation (as shown in the JITStats view) does not show any or very little background JIT compilation, there are several issues that may be responsible. Fundamentally a important design goal was to insure that background JIT compilation did not change the behavior of the program under any circumstances. Unfortunately, it means that the algorithm tends to bail out quickly. In particular
+ If your program has used SetProfileRoot and StartProfile, but JIT compilation (as shown in the JITStats view) does not show any or very little background JIT compilation, there are several issues that may be responsible. Fundamentally a important design goal was to insure that background JIT compilation did not change the behavior of the program under any circumstances. Unfortunately, it means that the algorithm tends to bail out quickly. In particular
- When modules are loaded, a module constructor could be called, which could have side effects (even this is very rare). Thus if background JITTing would cause a module to be loaded earlier than it otherwise would be, it could expose (rare) bugs. Because background JIT had a very high compatibility bar, it protects against this by taging each method with the EXACT modules that were loaded at the time of JIT compilation, and only allows them to be background JIT compiled after all those EXACT modules were also loaded in the current run. Thus if you have a scenario (say a menu opening), where sometimes more or fewer modules are loaded (because previous user actions caused different modules to load), then background JIT may not work well.
- If you have attached a callback to the System.Assembly.ModuleResolve event, it is possible (although extremely unlikely and very bad design) that background JITing could have side effects if the ModuleResolve callback returned different answers on the second run than it did on the first run. Because of this background JIT compilation is suspended the first time an ModuleResolve callback in invoked.
- Because any module lookup that fails, WILL call the ModuleResolve event before it finally fails, this means that any probing for modules which fail will also inhibit background JIT compilation.
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+ Tiered compilation is a feature that was introduced in .Net Core 2.1. It improves both startup performance and steady-state performance by hot-swapping between different compilations of the same method at runtime.
+
+ - Startup perf wins - The runtime requests that the JIT use minimal optimizations the first time a method is compiled. Later if the method is called frequently the method will be recompiled with more optimizations. This recompilation occurs on a background thread in parallel with other activity.
+ - Steady-state perf wins - The runtime will identify frequently called methods whose code was originally loaded from ReadyToRun (aka crossgen) images and recompile it using the JIT. The jitted code is often more performant than the original because it can take advantage of additional information that is only known at runtime.
+
+ Different compilations of the same method are refered to as tiers, and as of .Net Core 2.1 there are two of them, 'Tier0' and 'Tier1'. Tier0 is the initial code for each method, regardless whether it was obtained from the JIT or from a ReadyToRun image. Tier1 refers to the optimized jitted code that is compiled on a background thread
+ Enabling tiered compilation
+ In .Net Core 2.1 tiered compilation is an opt-in preview feature. It can be enabled either by any of these mechanisms:
+
+ - Set an app config switch in runtimeconfig.json "System.Runtime.TieredCompilation": "true"
+ - Set the msbuild property <TieredCompilation>true</TieredCompilation> in the application's project file
+ - Set the environment variable COMPlus_TieredCompilation=1
+
+ Understanding Tiered Compilation events
+ Each process shows a high level summary table indicating JIT time broken down by trigger. One of these triggers is 'Tiered Compilation Background.' This category contains all the Tier1 methods.
+ The tier0 methods aren't identified explicitly as they can come from several sources:
+
+ - If the method is present in a precompiled ReadyToRun image then the JIT was not run. There is no accounting in the JITStats view for code loaded from images.
+ - The method could be jitted by a foreground thread just prior to its first execution, in which case it is contained in the 'Foreground' group
+ - If the Background JIT feature is enabled the method's usage may have been accurately predicted and jitted in advance on the Multicore JIT background thread, in which case it is accounted for in the 'Multicore JIT Background' group
+
+ In the individual method listings the column 'Trigger' contains the value 'TC' for each Tier1 background recompilation due to Tiered Compilation
+
+
+
+
+
+
+
+
+
+
+
+
+