Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide a power save mode #38429

Closed
heejaechang opened this issue Aug 30, 2019 · 24 comments · Fixed by #39699
Closed

provide a power save mode #38429

heejaechang opened this issue Aug 30, 2019 · 24 comments · Fixed by #39699
Assignees
Labels
Area-IDE Developer Community The issue was originally reported on https://developercommunity.visualstudio.com Feature Request
Milestone

Comments

@heejaechang
Copy link
Contributor

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.

@gafter gafter added the Area-IDE label Sep 1, 2019
@vatsalyaagrawal vatsalyaagrawal added Feature Request Need Design Review The end user experience design needs to be reviewed and approved. labels Sep 4, 2019
@vatsalyaagrawal vatsalyaagrawal added this to In Queue in IDE: Design review via automation Sep 4, 2019
@vatsalyaagrawal vatsalyaagrawal added this to the Backlog milestone Sep 4, 2019
@sharwell
Copy link
Member

sharwell commented Sep 4, 2019

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

@heejaechang
Copy link
Contributor Author

tagging @kendrahavens @jinujoseph

looks like we are getting vote already.

@jinujoseph jinujoseph moved this from In Queue to Next meeting in IDE: Design review Sep 9, 2019
@sharwell sharwell moved this from Next meeting to Need Update in IDE: Design review Sep 9, 2019
@dibarbet
Copy link
Member

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.

@dibarbet dibarbet removed the Need Design Review The end user experience design needs to be reviewed and approved. label Sep 10, 2019
@lauxjpn
Copy link

lauxjpn commented Sep 11, 2019

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.

@mavasani mavasani self-assigned this Sep 17, 2019
@mavasani mavasani modified the milestones: Backlog, 16.4 Sep 17, 2019
mavasani added a commit to mavasani/roslyn that referenced this issue Sep 17, 2019
This PR adds support for ability to control analyzer execution (IDE code style analyzers and third party analyzers) and execution of service that searches NuGet packages and framework references to enable suggesting usings for types from them. We plan to add more options in future to allow users to control more functionality.

Addresses dotnet#38429
mavasani added a commit to mavasani/roslyn that referenced this issue Sep 23, 2019
1. Option to enable power save mode: Fixes dotnet#38429. This option turns off all the background analysis and also turns off remote host (RoslynCodeAnalysis service hub process) for C# and VB projects to reduce memory consumption in this mode. This option turns off most of the background analyses that are executed by the solution crawler. We still execute the bare minimum analysis for a reasonable editing experience: compiler analyzer to get compiler warnings/errors and also execute the add usings and remove unncessary usings analyzers. We can tune this required analysis set in future, as required.

2. Option to disable live analyzer execution: There have been lot of requests in past to give users a single knob to turn on/off execution of all Roslyn analyzers in the IDE (third party analyzers + IDE code style analyzers which are enabled by default).

I have also hooked up the low virtual memory listener which detects low VM and used to turn off just the full solution analysis to now instead turn on a forced power save mode for the current VS session (which also turns off full solution analysis, along with other background analyses).
@jinujoseph jinujoseph added the Developer Community The issue was originally reported on https://developercommunity.visualstudio.com label Sep 25, 2019
@jinujoseph
Copy link
Contributor

asked in DC

@kendrahavens
Copy link
Contributor

kendrahavens commented Sep 27, 2019

suggestion in DC and DC

Also a request to completely disable the screw driver appearing DC

@CyrusNajmabadi
Copy link
Contributor

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
Copy link
Member

alrz commented Sep 28, 2019

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

@mavasani
Copy link
Contributor

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
Copy link
Contributor

mavasani commented Sep 28, 2019

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

Awesome!

@jinujoseph jinujoseph modified the milestones: 16.4, 16.5 Oct 10, 2019
@deanvr
Copy link

deanvr commented Oct 25, 2019

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
Copy link
Contributor

@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
Copy link
Contributor

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 added a commit to mavasani/roslyn that referenced this issue Nov 5, 2019
Replaces the existing "Full Solution Analysis" option, with a background analysis scope to allow users to control the analysis scope for all solution crawler based background analysis.

Fixes dotnet#38429. Active file scope minimizes all the background analysis to the active files, saving on CPU consumption from background analysis on remaining files in the solution.

I have also updated up the low virtual memory listener which detects low VM and used to turn off just the full solution analysis to now set the background analysis scope to "Active file" for the current session.
@mavasani mavasani moved this from Need Update to Complete in IDE: Design review Nov 20, 2019
@mavasani
Copy link
Contributor

mavasani commented Nov 20, 2019

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 (provide a power save mode #38429).
  2. Allow me to configure if, when and how analyzers execute in the IDE - How to disable live code compilation/analysis in Visual Studio 2017? #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 provide a power save mode #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"

AnalysisScope

  1. For How to disable live code compilation/analysis in Visual Studio 2017? #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.
      run-on-build-run-live-analysis
    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
Copy link

chucker commented Nov 20, 2019

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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

mavasani commented Dec 6, 2019

@dennis-yemelyanov It will be available in Preview 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-IDE Developer Community The issue was originally reported on https://developercommunity.visualstudio.com Feature Request
Projects
IDE: Design review
  
Complete