Build Acceleration - Default to On

[kvenkatrajan]

Summary

In 17.5 Build Acceleration was released as an opt in feature and this had significant impact on build performance as detailed in the discussion board
Next Step is to turn this on by default.

Considerations

• Ability to turn on feature flag remotely and measurably increase the span of audience
• Iron out any devbox implications
• Identify installer projects and disable
• Identify true impact on pre/post build

User Impact

~80% increase in build performance:

• From 224sec to 5 sec
• From 26 to 1.5 sec
• Consistent 8sec in VS

Tasks

• Add feature flag to VS https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/486390
• Add code to check the feature flag Allow enabling Build Acceleration via a feature flag #9181
• Improve logging to improve awareness of the changed default Allow enabling Build Acceleration via a feature flag #9181
• Address known limitations
  • Disable Build Acceleration for known incompatible packages #9214
  • Allow opting out of package-based Build Acceleration disablement #9257
  • Disable Build Acceleration for Slow Cheetah #9258
• Opt in internal developers
• Allow the feature flag to be publicly visible https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/496924
• Change the feature flag to default to on https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/496925
• Update documentation to explain use of the new feature flag

[LevYas]

Hi, thanks for the improvement. In which version of VisualStudio it is set to ON?
I try to understand, whether I still need to specify the acceleration per project or not.

[kvenkatrajan]

hi @LevYas thanks for your interest. This has been turned on by default in 17.9 release for sdk style (.NET core) projects.

[govert]

The default setting for build acceleration changed in VS 17.9 (according to the last internal VS check-ins referenced in this issue). We are building SDK-style projects that target .NET Framework, and for our projects this update turned out to be a surprising and hard-to-track-down breaking change. (Even though the previous comment suggests it changed for "sdk style (.NET core) projects", our sdk style (.NET Framework)" project was affected.) The default changed with no indication in the Visual Studio release notes.

The behavior of the "FastUpToDate" build is different to the normal MSBuild in that additional transitive dependencies are copied to the output, where MSBuild would not copy these files. With build acceleration on, the extra files will be copied to output when either doing "Build" or starting to debug, which both trigger the "FastUpToDate" build and hence the extra copy. When doing a "Rebuild" or building after changes, the real MSBuild build is run, which does not copy the extra files. This is even more confusing, since extra files will remain in the output until manually deleted ("Clean" runs MSBuild, which will not remove the extra files).

Whether the extra files should be there or not is another matter, but having these two incompatible build behaviors is very confusing. In our case these files were not used, but broke things at runtime.

Furthermore, there are now two settings in Visual Studio with unclear interaction.

• Tools -> Options -> Environment -> Preview Features -> Enable Build Acceleration By Default
• Tools -> Project and Solutions -> SDK-Style Projects -> Up to Date Checks

in additional to the explicit project property <AccelerateBuildsInVisualStudio>.

It would be helpful to clean up and document these options, and to document this breaking change in the release notes for Visual Studio.

Finally, it would be helpful to know why the build behavior is different (why additional files are copied as part of the "FastUpToDate" build which would not be copied by a real MSBuild build). Even if there is an argument for why these files should be in the output, neither MSBuild builds nor previous Visual Studio version would put them there. One would expect the accelerated build in Visual Studio to only be an optimization and not introduce changed behavior.

[drewnoakes]

@govert we definitely want parity between MSBuild and Build Acceleration. Could you verify whether the issue you're seeing is the same as #9001 or #8728? If not, please file a new issue and include enough information to repro the problem, so we can investigate. Thank you and sorry for the trouble here.

[Maintenance-Partnership-Systems]

Hmm. I think I just opened another issue that relates to this topic - see #9416 (comment)

[govert]

@drewnoakes I've tried to write up our case in #9417
It's not exactly the same as the other issues, though it does fall in the category of 'gathering copy items'.