Add View Compilation about jitbench HOT 6 CLOSED

Rough instructions (powershell-based):

First checkout the precompilation branch

#Do this before you publish
$env:MvcRazorCompileOnPublish="true"

# We need to work around https://github.com/aspnet/MvcPrecompilation/issues/123
# print this do you can remember it's value
$env:DOTNET_SHARED_STORE 

$env:DOTNET_SHARED_STORE=""

# Do the publish
dotnet publish -c Release -f netcoreapp2.0 --manifest $env:JITBENCH_ASPNET_MANIFEST

# Set this back to its original value
$env:DOTNET_SHARED_STORE="C:\Users\rynowak\git\aspnet\JitBench\.store" 

# Now run it
cd bin\Release\netcoreapp2.0\publish
dotnet .\MusicStore.dll

With View Compilation

> dotnet .\MusicStore.dll
Server started in 606ms

Starting request to http://localhost:5000
warn: Microsoft.EntityFrameworkCore.Query[100102]
      Query: '(from Genre g in DbSet<Genre> select [g].Name).Take(__p_0)' uses a row limiting operation (Skip/Take) with
out OrderBy which may lead to unpredictable results.
Response: OK
Request took 628ms

Cold start time (server start + first request time): 1234ms


Running 100 requests
Steadystate min response time: 2ms
Steadystate max response time: 8ms
Steadystate average response time: 2ms

ASP.NET loaded from store

Baseline

> dotnet .\MusicStore.dll
Server started in 576ms

Starting request to http://localhost:5000
warn: Microsoft.EntityFrameworkCore.Query[100102]
      Query: '(from Genre g in DbSet<Genre> select [g].Name).Take(__p_0)' uses a row limiting operation (Skip/Take) with
out OrderBy which may lead to unpredictable results.
Response: OK
Request took 2301ms

Cold start time (server start + first request time): 2877ms


Running 100 requests
Steadystate min response time: 2ms
Steadystate max response time: 8ms
Steadystate average response time: 2ms

ASP.NET loaded from store

from jitbench.

/cc @noahfalk @JosephTremoulet @lt72 @russellhadley @DamianEdwards @davidfowl (and others I'm probably forgetting)

This is the performance impact of taking Roslyn off of the startup path. This will be the default experience for deployed/published apps. Runtime compilation is still the default for local development.

Yeah, you saw that right. It takes less than half as long to start up when the views are compiled on publish. That cuts 1673ms off of the first request. Server start and steady-state timings are virtually identical.

Interestingly enough the %age of CPU time as JIT time as reported by perfview is consistently between 35%-40%. This has been the case in every ASP.NET scenario we have measure (big and small, precompiled views, runtime compiled views and no views at all).

I still think that the runtime compilation scenario is the best one to track as the main scenario because:

1. It's the most expensive
2. It's a superset of precompiled views

Ideally we could also automate this as a secondary metric.

Github won't let me upload the perfview traces here, it says they are too big. Shoot me a mail if you want them (or use those instructions and have fun making your own).

from jitbench.

+1 for adding pre-compiled views as secondary metric.

from jitbench.

Thats a great result Ryan! For the secondary metric I'm happy to let you guys (ASP.Net) set priority, assuming you care about it and its cheap/easy to collect then I agree it would be good to have.

The 35-40% jit number is interesting, but I'm guessing what you are seeing is that Jit is running in a relatively fixed proportion to class loading and assembly loading while managed code execution time and dotnet startup time are fairly small players. It makes sense that jit <-> class loading is closely coupled, but deliberate scenario choices should be able to shift the balance between (jit + class loading) and assembly loading. For example with enough NGEN'ed images (jit+class loading) should drop near 0. Of course none of your scenarios do that by design.

from jitbench.

9bef199

from jitbench.

Added instructions to the readme and added the necessary dependencies

from jitbench.