Does BuildVision slow the build?

[PhilPJL]

First off. BuildVision is great, I had been looking for something that would give me this info for ages.

Second. If I build with BuildVision enabled/disabled I think there a 5-10% speed improvement with it disabled. It's hard to tell though when manually timing a build. This is on an 8700K machine building a 180 project solution. It takes ~50 secs with BuildVision and maybe down to 45 without. Do you think there's an issue?

[StefanKert]

Hi Phil!

First off thanks for the kind words :) I am glad that the extension helps you in your daily work.

There have already been some improvements on performance in #8 but you are right. There is a small slow down with BuildVision. As you can see in the following table I was facing a similar difference between BuildVision disabled and BuidlVision enabled:

Run	No BuildVision	BuildVision 2.1 alpha 1	BuildVision 2.1 aplha 2
1	00:00:29	00:01:50	00:00:34
2	00:00:28	00:01:41	00:00:30
3	00:00:31	00:01:49	00:00:31

So the difference with the latest version of BuildVision is around 5%. Especially for short buildtimes (< 5 min) the impact is a little bit higher. I guess this project is not OpenSource.

Btw I am really impressed by the really fast buildtime for 180 projects :)! That is amazing!

So to keep things short:

Yes, BuildVision does slow down the build a little bit, but I don´t know if this is a big deal. There is defintly room for improvement. Don´t know if this is actually an issue :), but if it is, we should create another issue specific for Performance Improvements. If so I would love to get some deeper insights on your measurements and if you have more figures I would love to see them to maybe use them to improve BuildVision :)

[PhilPJL]

Stefan,

our 180 projects has about 100k lines of code (according to VS code metrics). A lot of them are quite small.

You're impressed with the build time? So am I since my work VM typically takes 15 minutes to build the same solution. It can take up to 30 minutes if it's having a bad day. My new home machine is an 8700k + Samsung 870 Evo + 32GB RAM. It initially built everything in 2.5 mins. After ngen'ing the .NET compiler Nuget package it dropped to 1 min, and after excluding the build folder from Defender, it's down to 50 seconds - so extremely happy :) BuildVision isn't remotely an issue with my work VM, and isn't really an issue at home, but 5% of a 6 core CPU is a lot. Your extension is good, but I'm sure it's not really doing that much work.

I noticed an issue when running VS code metrics for the solution. VS appears to run a separate build for each project, which causes the BuildVision window to keep opening and closing, which is at least annoying, and possibly slows down generation of the code metrics although it's not something I use often (if ever).

[StefanKert]

Wow that is impressive!!

Thanks for the details, all of that sounds really interesting. Especially the defender and ngening part. Do you have any detailed measurements on this? Would be interesting to have some of these.

Fair enough. 5% is definitely a lot for 6 cores. I am currently pretty tied up with other stuff, but next month I got more time. Probably we can have a chat on this stuff to sort out some performance issues. Would be really interesting.

Regards the vs code metrics stuff: is it possible to create a separate issue for this with further information and repro steps? Probably we can add a condition to not reopen if code metrics analysis is ran.

[PhilPJL]

Sorry I don't have any detailed measurements.

Defender virus checks everything while the build is happening. I noticed it was using a lot of CPU so excluded the solution folder. That dropped the build time from 60-65 seconds down to 50-52.

All of our projects include the .NET compilers NuGet package. I was told the this isn't ngened, so build times will be slower than using the default VS compiler I haven't been able to replicate this result elsewhere but immediately after I updated Rider to the latest version my builds to drop from 150 seconds to 60. They reverted to 150 at one point but luckily ngen-ing csc.exe and vbcscompiler.exe in the compiler package tools folder got it back to 60. On other machines there is some improvement but nothing so dramatic.