Sdk: Improve CLI performance for RTM

[TheRealPiotrP]

Tracking issue for performance improvements for CLI for the 1.0.0-rtm milestone

Bugs

• [x] https://github.com/dotnet/cli/issues/2475 The elapsed time to complete the build emitted by dotnet build is lower than the actual time required to complete the command. - fit-n-finish [Post RC2]

  Enhancements

• [ ] ???? Add Performance automation [Post RC2]

• [ ] https://github.com/dotnet/cli/issues/2595 move telemetry to a fire-forget process
• [x] ???? consider / think about using VBCS compiler [Post RC2]
• [x] https://github.com/dotnet/cli/issues/2497 Reduce overhead of telemetry [Post RC2]
• [x] https://github.com/dotnet/cli/issues/2495 Share Project Graph within and across CLI invocations [POST RC2]

[muratg]

:eyes:

[tatalvit]

I tested RC1 and RC2. Created new project: "ASP.NET Core Web Application (.NET Core)" and "Empty" as ASP.NET Core template.

Test case A: 1) Run without debugging 2) wait for startup.cs to write "Hello world!" 3) modify text to "Hello world 2!" Ctrl+S 4) Hit F5 in browser.
Test case A results in RC1: IIS Express responds within 4-5 seconds with "Hello world 2!"
Test case A results in RC2: IIS Express responds within 4-5 seconds with "Hello world 2!" and avg compilation time is 2.3 seconds.

Test case B: One simple controller and view. Controller action has ViewData["Message"] = "Hello world!"; and view shows that message. 1) Run without debugging 2) wait for controller to write "Hello world!" 3) modify text to "Hello world 2!" Ctrl+S 4) Hit F5 in browser.
Test case B results in RC1: IIS Express responds within 4-5 seconds with "Hello world 2!"
Test case B results in RC2: IIS Express responds within 9-12 seconds with "Hello world 2!" and avg compilation time is still the same 2.3 seconds.

So what is happening in the background with MVC now in RC2? Where is the extra 5 seconds wasted?

[pedrogaspar]

Will this be fixed in time for rtm?
Compilation in rc2 is a lot slower than it was in dnx.

[Bartmax]

I want to add something.
I have the same solution on two windows pc.

One is old on medium hardware specs. (ssd sata, i7 2.6 Ghz, 8gb ram ddr3)
Second is fast hardware specs (ssd m2, i7 3.4 Ghz, 16gb ram ddr4)

Build time for each one is:

Slower Pc: 04.9031392
Fastest Pc: 04.4933136

Something is not right here. I would expect a bigger difference between both.
Also, in RC1 on slower pc, build time was about 00.9ish (4 seconds faster)

I'm sure the solution shouldn't be 5 seconds build time. It's one project (small) for only one TFM.

[pebezo]

Something is definitely not right. The compilation time went up several times compared to RC1 (haven't timed it).

[tatalvit]

Core 1.0.0-preview2-003121 slow to view changes: dotnet/cli#3883

[nth-commit]

Hey guys, don't get me wrong, loving the new framework. It's my love that made me want to chime in and express that compile times are seriously slow. A project that I have been working on for 3 months (not THAT much code, relatively, but still quite a bit and in ~5 separate project files) can often take more than a minute to compile. Before RTM (I went straight from RC1 to RTM) there was no noticeable lag, maybe 5 or 10 seconds MAX. Obviously this is going to turn a lot of developers off using dotnet core. Cheers.

[severisv]

Is it possible to get any information regarding this? Developing with dnx was a pleasure, but after the move to dotnet cli it is a frustrating experience.

Why was dnx fast and why is dotnet cli slow? Will we ever see dotnet cli perform as well as dnx did? When?

[nikolaschou]

I'm also annoyed by slow builds after upgrading from RC1 to 1.0 (RTM). Any news would be appreciated.

[GunterGlad]

Developing on Windows 10 + Visual studio is maxing out my CPU constantly. It is extremely slow. So please any performance gains would be appreciated.

[gulbanana]

dnx was fast because it was a holistic system optimised for only web use cases. it did everything itself, including in-memory compile, and VS was just a wrapper

the problem with dnx was that it was incompatible the rest of the ecosystem and with non-web use cases. the rc2/rtm approach, when used in VS. is fundamentally a hack to regain some compatibility: visual studio orchestrates, but calls the CLI commands to do most work, introducing considerable concept-translation overhead and scaling poorly to multiple-project solutions.

the next major release will solve this by inverting the system: msbuild, with its whole-solution understanding and incremental build optimisations, will be the source of truth. this will allow visual studio and dotnet CLI to separately invoke msbuild, returning us to pre-.netcore performance when working in a multiple-project IDE setup

this was one of the major reasons project.json had to go, and it really can't be fixed until then. but once that happens decent perf should be pretty much automatic.

[GunterGlad]

Well that is great news. Thank you. Just 1 question. When I can I get this? Now not looking for exact date. Just ballpark EG: Q1 2017? Thanks. Keep up the good work.

[rdghickman]

The 1.1 release on the roadmap is scheduled for "Fall" ie. autumn. So I guess a few months.

[gulbanana]

just to be clear- I don't work for Microsoft, so it's not my good work :) I agree that they should keep it up though!

[livarcocc]

Closing this issue as the issues being tracked here have been addressed.

2.1.300 now uses vbcscompiler. Our telemetry is not in a fire and forget separate process, but it is in a fire and forget thread. And, we also added perf tests to the SDK repo.