Consider disabling module auto-loading during IntelliSense

[daviwil]

Module auto-loading during IntelliSense is causing some issues for people, including session hangs and IntelliSense slowness. We use Get-Command to gather information about the currently active IntelliSense result. This causes the module containing the command to get loaded, and if the module misbehaves somehow, it can damage the rest of the session.

We should consider setting the $PSModuleAutoLoadingPreference to "none" before running Get-Command so that IntelliSense details are only gathered for modules that the user has loaded. To make sure we have cmdlet signature details, we could potentially just parse the tooltips of the completions if they're available without loading the module.

[TylerLeonhardt]

Could this autoloading be causing PowerShell/vscode-powershell#861 ?

[daviwil]

Nah, that issue is caused by the use of DSC. For some reason, having Import-DSCResource in a script slows IntelliSense to a crawl.

[adamdriscoll]

@TylerLeonhardt - I know this is old but this is kind of a pain in the butt for binary module developers. If I install UniversalDashboard, it will load it from the PSModulePath. If I specify a path in my script to load the module from a different directory, that won't work because even if I use -Force, the UD module has already been loaded from my path.

[rjmholt]

We run intellisense in the same runspace as the console so that Register-ArgumentCompleter and a few other things will work. We've looked into kicking intellisense into a different runspace/thread/process but PowerShell just doesn't support that today.

So turning off autoloading for intellisense while keeping it on in the console is slightly complicated. Essentially we need to do some reflection to reach in and set the autoloading preference variable here:

PowerShellEditorServices/src/PowerShellEditorServices/Services/Symbols/Vistors/AstOperations.cs

Lines 35 to 140 in 7ebc64e

	/// <summary>
	/// Gets completions for the symbol found in the Ast at
	/// the given file offset.
	/// </summary>
	/// <param name="scriptAst">
	/// The Ast which will be traversed to find a completable symbol.
	/// </param>
	/// <param name="currentTokens">
	/// The array of tokens corresponding to the scriptAst parameter.
	/// </param>
	/// <param name="fileOffset">
	/// The 1-based file offset at which a symbol will be located.
	/// </param>
	/// <param name="powerShellContext">
	/// The PowerShellContext to use for gathering completions.
	/// </param>
	/// <param name="logger">An ILogger implementation used for writing log messages.</param>
	/// <param name="cancellationToken">
	/// A CancellationToken to cancel completion requests.
	/// </param>
	/// <returns>
	/// A CommandCompletion instance that contains completions for the
	/// symbol at the given offset.
	/// </returns>
	public static async Task<CommandCompletion> GetCompletionsAsync(
	Ast scriptAst,
	Token[] currentTokens,
	int fileOffset,
	PowerShellContextService powerShellContext,
	ILogger logger,
	CancellationToken cancellationToken)
	{
	if (!s_completionHandle.Wait(0))
	{
	return null;
	}
	try
	{
	IScriptPosition cursorPosition = (IScriptPosition)s_extentCloneWithNewOffset.Invoke(
	scriptAst.Extent.StartScriptPosition,
	new object[] { fileOffset });
	logger.LogTrace(
	string.Format(
	"Getting completions at offset {0} (line: {1}, column: {2})",
	fileOffset,
	cursorPosition.LineNumber,
	cursorPosition.ColumnNumber));
	if (!powerShellContext.IsAvailable)
	{
	return null;
	}
	var stopwatch = new Stopwatch();
	// If the current runspace is out of process we can use
	// CommandCompletion.CompleteInput because PSReadLine won't be taking up the
	// main runspace.
	if (powerShellContext.IsCurrentRunspaceOutOfProcess())
	{
	using (RunspaceHandle runspaceHandle = await powerShellContext.GetRunspaceHandleAsync(cancellationToken))
	using (System.Management.Automation.PowerShell powerShell = System.Management.Automation.PowerShell.Create())
	{
	powerShell.Runspace = runspaceHandle.Runspace;
	stopwatch.Start();
	try
	{
	return CommandCompletion.CompleteInput(
	scriptAst,
	currentTokens,
	cursorPosition,
	options: null,
	powershell: powerShell);
	}
	finally
	{
	stopwatch.Stop();
	logger.LogTrace($"IntelliSense completed in {stopwatch.ElapsedMilliseconds}ms.");
	}
	}
	}
	CommandCompletion commandCompletion = null;
	await powerShellContext.InvokeOnPipelineThreadAsync(
	pwsh =>
	{
	stopwatch.Start();
	commandCompletion = CommandCompletion.CompleteInput(
	scriptAst,
	currentTokens,
	cursorPosition,
	options: null,
	powershell: pwsh);
	});
	stopwatch.Stop();
	logger.LogTrace($"IntelliSense completed in {stopwatch.ElapsedMilliseconds}ms.");
	return commandCompletion;
	}
	finally
	{
	s_completionHandle.Release();
	}
	}

However, doing so might be a performance issue, since it means either executing PowerShell or doing some risky reflection in a multithreaded scenario.

[adamdriscoll]

Cool. Thanks for the info. I just wanted to bring up that this was an issue for me and at least one other user I know of.

[SeeminglyScience]

The other problem is how limited intellisense would be without autoloading. By default, only Microsoft.PowerShell.Core and PSReadLine are imported, which only yields a total of 64 cmdlets. You'd have to manually import a whole lot of modules to make intellisense useful.

One day I hope to see a future where PowerShell has a completion API that is entirely static, based on MetadataReader and AST analysis. Until then, I usually just run Restart PowerShell Session before I manually import the WIP version of the module I'm working on.

[TylerLeonhardt]

Cc @SteveL-MSFT @daxian-dbw an interesting discussion here.

[TylerLeonhardt]

I also wanna chime in and say that the TEMP debugging feature which allows you to debug in a brand new integrated console (also which is fixed in the latest preview extension) is a perfect candidate for binary module debugging. All you have to do is use the:

"createTemporaryIntegratedConsole": true in a launch debug configuration.