`DebugService` has high cost

[jrieken]

• Profile startup/reload (w/ simple text editor, just the explorer visible)
• Drill into code editor creation
• Notice that ~30% its creation time is spend in the CallStackEditorContribution contribution

That itself is cheap but it "force creates" the delay/lazy debug service which causes a ripple of events and other things. It would be better if we can keep this lazy and depend on the service to soon

[jrieken]

This might a bit of a cat and mouse game because once this contribution is more lazy, the next is on the hook (BreakpointEditorContribution). Still, I think it's worth it. After editor creation and while loading the contents for the editor there could be enough idle time to create the debug service.

Alternatively, creation of the debug service could be made more light weight...

[bpasero]

👍 also saw this in the profiles

[roblourens]

Sorry, what do I need to do to make this editor contribution lazy?

Both of these contribs' constructors only depend on the debugService to add some event listeners, and there's no reason to force the service to be created just for that, but I don't know how to make an editor contribution lazy.

[roblourens]

Could wrap its registration in a workbench contribution that is created delayed?

[jrieken]

Editor contributions cannot be made lazy, they are picked up on start. However, you can make it more lightweight. Today the contribution listens to debug events straight away (and that subscribing instantiates the service) but at that point there is no point in listening because the editor has no model yet. So, this case will always happen.

Listening only when having a model might give you enough slack/idle time in which the debug service can be constructed but I have doubts.

I think the underlying issue is the size and breath of the debug service. The service has many dependencies and does many things when it's being created and I wonder if all that must be in a single service or if the service can be more lazy.

Looking at what's happening:

• a good chunk is spend create the ConfigurationManager which does something expensive with configs
• another good chunk is spend on context key creation and subsequent event handling cause by that
• a large chunk is spend because a file system provider is registered which causes a big cascade of events

I believe each of these steps should critically looked at and we should also examine down-level effects, e.g why is does registering a file cause such an expensive label-re-render everywhere etc... I'll rename the title of this issue accordingly

[roblourens]

Made these changes

• The 3 debug editor contributions don't add any listeners until the editor has a model
• The fs provider is not registered until debugging starts
• Small context key optimizations

So at least the DebugService is not created until the editor has a model, but some of the work is still earlier than needed.

It would be cool if simply listening to an event would not instantiate the service, but would return a proxy event emitter that would be hooked up to the real thing when the service gets instantiated for some other reason. That would require the InstantiationService proxy to know that something is asking for an event, maybe by looking at the onDid... name pattern.

The DebugService creation looks like this now

More notes

• Maybe the ConfigurationManager can lazy load its configs. They should only be needed when the debug view is opened, or when the statusbar item appears, which is a lazy workbench contrib
• I could see the AdapterManager and ConfigurationManager being their own services. Maybe another can wrap the model. Splitting up DebugService is going to be hard though since the parts seem very intertwined.
• The context key initialization seems slow because it causes views to be enabled, which causes actions to be registered, but I don't think there's a way to avoid all that.
• Then there's the loading of the breakpoint model, which takes some time but needs to happen early, I don't want breakpoints to blink into existence noticeably late
• The breadcrumbs/filesystem provider should be easy at least, I leave that to you https://github.com/microsoft/vscode/blob/5f68cf3b1ff11bfba4d2c2df22541c250799abd1/src/vs/workbench/browser/parts/editor/titleControl.ts#L168-L169 give BreadcrumbsControl a way to signal that it is not missing a fs provider? Or just check isHidden before calling update?

[jrieken]

It would be cool if simply listening to an event would not instantiate the service, but would return a proxy event emitter that would be hooked up to the real thing when the service gets instantiated for some other reason

Love it. @alexdima and I had discussed the same thing yesterday. I'll give it a try and see how much we can save like that

[jrieken]

but would return a proxy event emitter that would be hooked up to the real thing when the service gets instantiated for some other reason

➡️ https://github.com/microsoft/vscode/pull/162928

[jrieken]

Maybe the ConfigurationManager can lazy load its configs. They should only be needed when the debug view is opened, or when the statusbar item appears, which is a lazy workbench contrib

FYI - we have IdleValue and Lazy to make such tricks easy

The context key initialization seems slow because it causes views to be enabled, which causes actions to be registered, but I don't think there's a way to avoid all that.

Dragging in @sandy081 - it might actually be better to register the actions as soon as the views are registered (not when they are enabled) and to enable the actions with the same context keys

The breadcrumbs/filesystem provider should be easy at least, I leave that to you

Will do - it is bizarre. A single (1) file label is being rendered and it seems that inferring class names for the theme/file icon is very expensive...

[roblourens]

Sweet, that was fast. But I have to do more refactoring to take advantage of it, I have all of this this.debugService.getModel().onDid... and this.debugService.getViewModel().onDid... which has always bugged me. Those can probably be separate services too.

             ->    DebugModelService
DebugService ->    DebugViewService
             ->    DebugConfigurationService

[sandy081]

May I know if you meant about following actions?

https://github.com/microsoft/vscode/blob/9cc932ee6bb1b6b9a8ed0cc4500fb33dae1d1db6/src/vs/workbench/services/views/browser/viewDescriptorService.ts#L740

[roblourens]

I think so