Extension Lifecycle (spawn and kill processes, caching of items, optimized loading)

[joadoumie]

Description of the new feature / enhancement

We need to conduct a deep dive into how we manage extensions over the course of their lifetime.

Extension processes should not remain around for the entire lifecycle of the palette itself. As part of this investigation, we should consider:

1. How do we properly spawn and kill extensions?
2. How do we ensure speedy UI/UX if extension processes are not constantly lying around
3. How can we potentially cache top level commands from extensions so we don't have to always have them around.

Scenario when this would be used?

This will be abstracted away from extension developers, but will become core to the command palette

Supporting information

No response

[zadjii-msft]

Here's a weird wacky thing today:

Every time we come back to the main page, we call IExtension.GetProvider. And in the sample, we always instantiate a new one on the call to that. So every extension we have? Instantiates a new object each time we get to the main page.

Twofold fixes:

• Best practice: Extensions should probably have a single static ICommandProvider instance that they return out.
• We probably shouldn't call that every time we come back? Like, we can call TopLevelCommands, but GetProvider? We should already have that!