Roslyn: provide a power save mode

[heejaechang]

we have been adding more and more features to IDE. it is long-tail features so it always helps some portion of our users. but there is also another portion of users who don't care that features or want to reduce noise or reduce system resource consumed from those features that they don't use much.

these people have been asking a way to disable those features altogether. and let those features only run when it is explicitly asked.

basically no solution crawler running, no background compilation running and etc.

it requires design meeting, but similar to power save mode other IDE team provides for exactly same reason.

[sharwell]

Ideally the trigger for this mode would be provided by the core editor or platform, and Roslyn would simply respond to it.

[heejaechang]

tagging @kendrahavens @jinujoseph

looks like we are getting vote already.

[dibarbet]

Design review outcome

1. @mikadumont / @kendrahavens to file a suggestion bug to collect more feedback.
2. Sync with platform team on implementing this editor-wide as all teams will need to respect this mode.
3. Prototype a version for live code analysis in order to settle on a useful API and what features should be included / not included. Starting with features like diagnostics, we can disable most diagnostics (except for compiler errors and fixers) and have the others only be invoked on request.

[lauxjpn]

I suggest making this not just an event, to which components (like Roslyn) might react to, but include a mechanism for components supporting the mode to register themselves with, so there could be implemented some form of dialog, that lets you choose, which component to disable/power down when entering power safe mode.

[jinujoseph]

asked in DC

[kendrahavens]

suggestion in DC and DC

Also a request to completely disable the screw driver appearing DC

[CyrusNajmabadi]

I'm very wary about thsi. People are reporting slowness, and they're claiming it's due to a specified feature, but it's not clear to me how we're verifying what the actual root cause is. Code-analysis, for example, should not impact typing unless somethng has broken internally. It's run out of process and at low-priority. If it actually is slowing things down, then something is very messed up and needs to be fixed.

[alrz]

I haven't looked at those reports but I expect some people want to disable roslyn just to use another analysis tool.

[mavasani]

I feel this feature is being looked at the wrong way in multiple ways. The core feature is:

1. I am using a tool that allows me to perform my daily tasks.
2. There are some minimum set of features that I need to accomplish these tasks in a reasonable way.
3. Tool provides additional rich functionality to help me perform these tasks much more easily, efficiently and correctly.
4. I appreciate all the rich functionality and absolutely require it for different times of my development phases. However, there are certain scenarios where I want a bare minimum experience:
   
   
   
   1. Task based: I am debugging some subtle bug and not trying to improve existing code or write new code or perform any heavy refactoring.
   
   
   2. Resources based: I am being constrained by resources such as battery, memory, etc. which can happen with any device based on situation, other parallel applications being executed on the device, etc.
   
   
   3. Functionality based: Some unknown performance or reliability regression in any of the additional rich functionality. Bugs happen in any tool, no matter how effectively tested, and they should be investigated and fixed. I am ready to provide feedback report to assist in fixing these, but I would appreciate if I can get unblocked from using the tool and get minimum functionality by disabling all the rich functionality temporarily.
   
   
   4. Preference based: I only prefer to use a tool with minimum functionality at certain or all times in my development. I would appreciate if the tool gave me explicit control over the feature set or a top level knob to control how I wish to operate it without forcing full functionality on me all the time.
   
   

IMO at the core, any tool with rich functionality has a much bigger value add if it configurable by the users to run as they want when they want. We should continue delivering productivity value add and never ever use these knobs as a way to de-prioritize bugs and regressions in configurable features - they are part of default experience for the tool and ought to be prioritized and fixed. Yes, there is possibility that some users would be less keen on providing reports or additional data to help us fix these if they can easily workaround it, and that makes fixing these harder for us, but that should never undermine the huge productivity boost that majority of customers get from the ability to take better control over its execution to meet their current requirements.

[mavasani]

I also feel this should be implemented as multiple operational modes:

1. Power save mode: Constrained by CPU usage/power. I don’t wish to turn off features, just not spend CPU cycles on background analysis or caching and willing to spend them whenever I explicitly trigger a feature and understand there might be an initial performance hit. The way our phone’s battery save mode works.
2. Lightweight mode: Constrained by any of the factors above, and just wish minimum functionality and/or resource usage for an acceptable IDE experience.
3. Default mode: What we enable today for customers, and always consider to be our recommended tool usage mode.
4. Enhanced analysis mode: Ability to turn on disabled by default features, that may be a hindrance or noise for regular usage but can help users to improve their development experience and code at specific phases of their development cycle. Much like the post-build static analysis tools that can be executed offline at various phases to improve code quality.

We should explicitly document what each mode enables or disables to allow users to make informed choices.

[CyrusNajmabadi]

@mavasani I'm firmly behind the idea of different modes (or feature knobs) to provide a fundamentally different experience for users. I have no issue with that.

What i'm concerned about are links to unverified claims by people that "feature X is awful and making my experience slow, give me a way to shut it off". These are not valid claims in support of this work without actual verification and validation that the claims are true.

[CyrusNajmabadi]

Note: i agree mostly with your breakdown of the features to offer. I would expand on one of them a bit:

Lightweight mode: Constrained by any of the factors above, and just wish minimum functionality and/or resource usage for an acceptable IDE experience.

I honestly think this should just be a set of options (and possibly one easy way to toggle all of them). What is 'lightweight' will be person dependent, and i think it would be 100% fine to allow individual knobs (and a top-level option) to let users opt out of particular features they would prefer to not have running right now.

As an example, i view "squiggles" versus "the error list" as very different features, even though they're entirely about diagnostics. I might want to disable squiggles, but leave on hte error list (or vice versa). I worry about us defining what "minimum functionality and/or resource usage for an acceptable IDE experience" is, rather than letting the user decide.

Thanks! :)

[mavasani]

I agree with you @CyrusNajmabadi - we should not close or resolve any community feedback about potential bugs against this feature. Pointing this as a feature that could help them get unblocked easily in future is fine, but we should investigate all filed feedback reports.

Regarding multiple options- that was my initial implementation, but we felt it might overload the users with information. We will start with top level knobs and keep adding sub-options and tuning the defaults based on user feedback.

[CyrusNajmabadi]

Regarding multiple options- that was my initial implementation, but we felt it might overload the users with information.

Personally, i'm skeptical about that. I think the knobs we would provide would be fairly clear and easy to enumerate for customers. But it's also not critical and can be something changed in the future. :)

we should not close or resolve any community feedback about potential bugs against this feature.

Agreed :)

Thanks!

[mavasani]

@CyrusNajmabadi I have re-opened couple of DC feedback items that were about customers seeing real performance issues and requested them to provide performance traces. Couple other DC feedback items were actually customers requesting more control over the functionality in the IDE, not any performance issue.

[CyrusNajmabadi]

Awesome!

[deanvr]

Please we need and option to turn off live code analysis, so

1. On
2. Off
3. Post build

Most professional shops now days are using laptops with cpu power management, you need to make sure the teams making these great tools are using hardware kit akin to the target audience please! I don’t want to move of VS, but I’m scratching my head, whilst making a cupa tea waiting for my ide to become responsive :(.

[CyrusNajmabadi]

@deanvr

but I’m scratching my head, whilst making a cupa tea waiting for my ide to become responsive :(.

Note: Live Code Analysis shouldn't be affecting IDE responsiveness. If it is, that's just a straight up bug. Often times i've seen people report VS slowness against Roslyn when it's not roslyn at all (or at least, not live-code-analysis that is the problem).

If you are dealing with VS responsiveness issues, please file bugs using the instructions found here: https://github.com/dotnet/roslyn/wiki/Reporting-Visual-Studio-crashes-and-performance-issues#performance-issues

This will help get a perf trace to the Roslyn team so they can investigate and assign to the right team as appropriate (or keep in Roslyn if it really is a roslyn issue).

Thanks!

[CyrusNajmabadi]

Most professional shops now days are using laptops with cpu power management, you need to make sure the teams making these great tools are using hardware kit akin to the target audience please!

FWIW, i use a dual core laptop, and i edit the Roslyn project itself without issues. Occasionally there are regressions that cause problems, and i try to file these issues myself to get them addressed. However, by and large, VS/Roslyn should work fine in these scenarios. If it isn't, then those are just perf problems that need to be root-cause fixed. Adding new features won't generally help here.

[mavasani]

Update

This feature requested has been implemented for VS2019 16.5 release. Let me summarize a few things here for clarity.

What is "Live Code Analysis" for Managed projects?

Visual Studio executes a bunch of background analyses while you are editing source files in the editor. Some of this is required minimal analysis for acceptable IDE editing experience, some of this is to improve responsiveness for IDE features by proactively analyzing closed files in the solution and some of this is to enable additional rich functionality (such as IDE code style suggestions). Based on the functionality, the analyses can be bucketed as follows:

1. Background computation of diagnostics (errors/warnings/suggestions):
   
   
   
   1. Compiler diagnostics
   
   
   2. Roslyn analyzer diagnostics (built-in IDE analyzers for code style suggestions + analyzer NuGet packages installed for project)
   
   
2. Other background analyses: For example, background parsing of open files, background compilation of projects with open files to realize symbols for improved responsiveness of IDE features, building syntax and symbol caches, detecting designer association for source files (like forms, controls, etc) in projects, etc.

Feature requests

1. Allow me to configure IDE to work at minimal background analysis - this issue (https://github.com/dotnet/roslyn/issues/38429).
2. Allow me to configure if, when and how analyzers execute in the IDE - https://github.com/dotnet/roslyn/issues/24513. By default analyzers always execute during live analysis + build. However, I would like to choose from one of the following workflows (there may be more):
   
   
   
   1. Execute analyzers only during build
   
   
   2. Execute analyzers only with an on-demand "Run Code Analysis" command, but not during live analysis and/or build.
   
   
   3. Execute analyzers with reduced scope for live analysis (i.e. only current document OR open documents) and execute them for a broader scope (specific project or entire solution) with an on-demand "Run Code Analysis" command whenever I wish to run analyzers.
   
   

Support added in VS2019 16.5

1. For https://github.com/dotnet/roslyn/issues/38429: Users can now explicitly change the scope of all Roslyn based background analysis to current document from Tools Options. This includes all diagnostics computation. Note that the default scope is "Open Documents and Projects"

1. For https://github.com/dotnet/roslyn/issues/24513:
   
   
   
   1. Users can now explicitly choose to opt out of analyzer execution during build and/or live analysis from the Code Analysis project property page. Starting VS2019 16.5, the Run on live analysis checkbox on that property page is a per-user option that gets written to a .csproj.user file and is also respected for built-in IDE analyzer execution. However, if the configuration is a repo preference instead of a personal user preference, you can configure this at a solution level Directory.Build.props with the MSBuild property RunAnalyzersDuringLiveAnalysis.
      
      
   
   
   2. Users can now execute Run Code Analysis command to perform on-demand analyzer execution from top level Build menu or top level Analyze menu or from the Analyze and Code Cleanup menu by right clicking the project/solution node in solution explorer. Prior to VS2019 16.5, this was used to run legacy FxCop analysis, but this command now runs Roslyn analyzers.
   
   

Combining the above features, users can choose any of their preferred code analysis workflows for analyzer execution OR configure scope for all the Roslyn based background analysis.

We will ensure that the above support is documented when VS2019 16.5 is released. We will look forward to any further feedback on code analysis configuration support once these features are available.

[chucker]

For #38429: Users can now explicitly change the scope of all Roslyn based background analysis to current document from Tools Options. This includes all diagnostics computation. Note that the default scope is "Open Documents and Projects"

Have you considered allowing the radio button selection to depend on the active Windows power profile (high performance, on battery, etc.)? Was this discarded because of UI complexity?

[mavasani]

Have you considered allowing the radio button selection to depend on the active Windows power profile (high performance, on battery, etc.)? Was this discarded because of UI complexity?

This was indeed suggested and considered, but I did not get to implementing it in the initial feature set. Feel free to file a separate issue.

[dennis-yemelyanov]

@mavasani , should the "Background analysis scope" option be available in version 16.5.0 Preview 1.0? I just installed this version, but the option doesn't seem to be there

[mavasani]

@dennis-yemelyanov It will be available in Preview 2