Skip to content

Provide an option to disable usage of Get-Help for IntelliSense results #166

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

Closed
verysmallposhscript opened this issue May 4, 2016 · 11 comments
Labels
Issue-Bug A bug to squash.
Milestone

Comments

@verysmallposhscript
Copy link

There's a long delay in intellisense results on default cmdlets, as shown in the gif. It's taking upwards of 10 seconds after typing in a partial cmdlet name before the intellisense results pop up.

2016-05-04_14-25-02

@daviwil
Copy link
Contributor

daviwil commented May 4, 2016

Hey @verysmallposhscript, thanks for the report. I have a feeling that the delay is coming from our use of Get-Help to gather the details for the cmdlet. It's likely that I'll need to add an option to disable this help querying when the user finds it slowing down their IntelliSense. I'll add this in an upcoming release.

Regarding the tab-completion issue you mentioned on Reddit, I'll talk to the VS Code team to see if they can add a way to cycle through IntelliSense results so that we can have an experience that's more like what PowerShell developers are used to.

@daviwil daviwil added the Issue-Bug A bug to squash. label May 4, 2016
@daviwil daviwil changed the title Long delay on intellisense Provide an option to disable usage of Get-Help for IntelliSense results May 4, 2016
@daviwil daviwil added this to the Backlog milestone May 4, 2016
@ChrisLynchHPE
Copy link

I hope progress can be made on this issue. Intellisense either becomes broken (with 'Loading...' and eventually just goes away), or extremely slow to generate the list (even on a blank line). It makes development of PowerShell libraries really difficult.

I should also specify that this happens for me when I'm developing within my main module (which currently has >70K lines of code). When I'm in a new PowerShell file, no issues.

VSCode: 1.4.0
PowerShell Extension: 0.7.0
Windows 10 $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14905.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14905.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

@daviwil
Copy link
Contributor

daviwil commented Aug 24, 2016

Hey Chris, I'm going to prioritize this issue now that the cross-platform work is done. It's annoying me too at times.

@verysmallposhscript: How's the delay going for you in the latest releases of VS Code (1.4.0) and the PowerShell extension (0.7.10?

@ChrisLynchHPE
Copy link

Thanks! I was using Visual Studio 2013, but VSCode is so much lighter overall. I love the progress both projects have made. Hopefully this performance bug can be squashed!

@rkeithhill
Copy link
Contributor

@daviwil It would be nice if VSCode would allow us to return the completion list in phases. First we give VSCode the raw-ish completion data sans help. Then as someone moves up and dow the list, VSCode queries to see if there is more "info" for that completion item. Kind of like how they handle scopes today with the expensive property. Perhaps it is only when expensive is true that VSCode asks for more info on a particular completion.

@daviwil
Copy link
Contributor

daviwil commented Aug 26, 2016

Technically they do allow that right now, there's an initial "completions" request that gets the list and then the "resolve" request that asks for further details about the currently selected completion. It could be that using Get-Help to get cmdlet details could be causing a slowdown.

@rkeithhill
Copy link
Contributor

@daviwil Do we spin up the Get-Help task on another thread right after the initial request? And do (should) we cache that information? Ideally, the resolve request would come in and we'd either have the cache entry populated or not and return quickly. Over time, the Get-Help bg task(s) would finish and fill in the cached data? Just brainstorming a bit here.

@daviwil
Copy link
Contributor

daviwil commented Aug 26, 2016

Crap, GitHub totally wiped out the text I had written here :( Anyway, we invoke Get-Help right after the user highlights one of the completion results they get back (the resolve step). I've filed an issue on the PSES repo to track the need for a cache:

PowerShell/PowerShellEditorServices#280

@daviwil daviwil modified the milestones: 0.8.0, Backlog Sep 8, 2016
@daviwil
Copy link
Contributor

daviwil commented Dec 7, 2016

So it turns out that this may be coming from the PowerShell engine instead of Get-Help like I originally thought (see issue #361). I'll talk to some folks today to see if I can figure out a resolution for 0.8.0.

@daviwil
Copy link
Contributor

daviwil commented Dec 9, 2016

Yes, this is a problem with the completion engine in PowerShell v5. Get-Help was wrongly accused. I'm going to close this issue now since it probably isn't needed. If anyone has strong feelings about it, I will be happy to reopen it.

@daviwil daviwil closed this as completed Dec 9, 2016
@ChrisLynchHPE
Copy link

So I'm circling back on this topic. What is the answer here to this issue? I still experience extremely slow performance with PSES, and have to either restart VSCode or PSES after a period of time (like once an hour).

Windows 10 Insider Fast Ring (currently 15048, Surface Pro 3, Core i5/8GB/256GB)
VSCode 1.10.2
VSCode-PowerShell 0.9.0

[PS] C:\Users\chris> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15048.0
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15048.0
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug A bug to squash.
Projects
None yet
Development

No branches or pull requests

4 participants