@brettfo will this slow down builds using the proto compiler?

Possibly on the first launch (the hot path should be jitted for subsequent invocations), but only if you were running as admin, which I don't think anybody actually is.

@brettfo

I think most of us do open administrator command windows. The Jit would have to compile virtually all of the FSharp.Compiler.Private.dll and FSharp.Core.dll every single dll or .exe it builds. It comes close to doubling the build time.

When we move over to the coreclr proto compiler if we can figure out crossgen, we can probably do this, otherwise it's painful.

Kevin

Scary error message:

1) Error : FSharp-Tests-Core+CoreTests.load-script
System.ComponentModel.Win32Exception : Operation did not complete successfully because the file contains a virus or potentially unwanted software
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at Scripting.Process.exec(CmdArguments cmdArgs, String workDir, FSharpMap`2 envs, String path, String arguments) in D:\j\w\release_ci_pa---866fd2c3\src\scripts\scriptlib.fsx:line 136
   at [email protected](CmdArguments cmdArgs) in D:\j\w\release_ci_pa---866fd2c3\tests\fsharp\test-framework.fs:line 421
   at [email protected](FSharpFunc`2 fCont, CmdArguments cmdArgs) in D:\j\w\release_ci_pa---866fd2c3\tests\fsharp\test-framework.fs:line 408
   at [email protected](String args) in D:\j\w\release_ci_pa---866fd2c3\tests\fsharp\test-framework.fs:line 430
   at [email protected](String x) in D:\j\w\release_ci_pa---866fd2c3\tests\fsharp\test-framework.fs:line 430
   at FSharp-Tests-Core.CoreTests.load-script() in D:\j\w\release_ci_pa---866fd2c3\tests\fsharp\tests.fs:line 871

@dotnet-bot test Windows_NT Release_ci_part2 Build please // a single test humorously failed with Operation did not complete successfully because the file contains a virus or potentially unwanted software, possibly due to conflicting AV on the Jenkins image; test passes locally.

On a related note I'm timing .\build.cmd ci_part1 now, both with and without ngen (as admin) to see what the real difference is.

I would want the compiler NGEN'd on my normal compiler development loop. (Obviously it has to be ngen'd on Visual Studio install as well but I assume that's not changing)

TBH I'd also expect it NGEN'd on our CI automated test runs - I haven't checked if that's the case though. There is always a thin chance of an NGEN bug being exposed by our testing and if so we would like to catch it as early as possible

ngen.exe gives a pretty big boost to local development so I'll close this PR. I've also merged #4002 which switches back to delay signing because those can actually be ngen'ed.