Change:
The -function supports a -argument. With  only proxies of services are injected and the actual instantiation happens in "slack/idle" time or at time of first actual use (whatever comes first). This is often overlooked and the default (, eager) is used. This issue is about: revisit existing eager usages and check if they can support delayed instantiation. This is the preferred way, helps startup performance , and is usually possible make the eager variant explicit, use , and feel a little bad about it Note that should only be needed if your service is doing something "by its own", like reading files or so, which is vital to other parts of the system. This should be the exception because most services offer something (a service) to others which means can be delayed until needed
starting with you because many of your services show as eager
adopted those service I own
you are next :-)
Went over the ones I consider owning and found some that can be lazy: Some observations: would be nice to somehow signal back that service cannot be lazy so that we know which ones are not acknowledged (I guess that is the purpose of this issue but might be nicer to validate in code) services that are implemented from a workbench part are instantiated on startup anyway because workbench parts are never lazy (even when hidden) I was not so sure for the ext-host services, they seem to require the main side proxy in their constructor so I left them, maybe we do a pass at once in those
Also did which forces every remote service (i.e. a service that talks to the main process or shared process) to be lazy. All of these services did already declare laziness but now its just enabled by default.
I like - I'll add another falsy value like "eager" or so
This would be useful for revisiting.
You can now use to mark a service as purposefully eager
I think another set of lazy services to look at is those that do not use but just :     I assume setting a to lazy, has the same effect? //cc since many services are extension related, especially in the non-workbench-window processes.
Yeah, it is the same
Adding me and back for in the ones of
does quite a few, even those that I do not consider owning.
Went through all services I own in all processes and adopted.
My change in results in exceptions: I wonder if we hit a case where lazy instantiation does not work well with a proxy when there is another proxy involved, because for some of the main-side services we use a utility to expose the service to another process: I think given this I will have to go back to eager instantiation for those services that are remote accessible. Likely an issue because I am enumerating the properties here to know which ones are events. Not 100% sure I can workaround this by doing this at a later stage when the lazy service is actually instantiated...
Right, this seems to be because of double usage of proxies. Because, those services on shared process which I made lazy and support channels seem to work as I do not use util.
Makes sense to keep them eager. I also believe that a proxy of a proxy doesn't help in perf. At the end this might be a bug with the delay-proxy as it likely doesn't react to APIs that's called on it to fullfill the contract
Adding following to the list of usage
Yeah it will not change much in perf, will review more carefully again tomorrow, for now I revert to unblock insiders:
Ok, second attempt: (its quite tricky to know whether a service is proxied or not, you have to do a fulltext search ala )
Adding and for your services
I don't believe my services can be lazy. The resolver is definitely needed immediately at startup especially if you're opening something from the code-cli. If the telemetry service is lazy we also miss recording any startup events. Feel free to correct me if I'm wrong as I am not super familiar with how lazy instantiation works
Only if the telemetry service logs messages by itself, e.g without any external consumer calling on it. As soon as a consumer starts to use the service it is being created and things works
The should stay eager as the constructor restores the last used colors from storage. This needs to happen as quickly as possible for a flicker free startup experience.
That makes sense but please "document" this via
Thanks everyone!

Discussion:
} } <del> registerSingleton(ICodeLensCache, CodeLensCache, false); </del> <ins> registerSingleton(ICodeLensCache, CodeLensCache, true); </ins>