Faster workspace loading

[slemeur]

Goal

The ultimate goal of this specification is to provide a faster loading (in time) of a workspace so the user is able to interact with his files as fast as possible.

This epic list various tasks in order to provide optimizations to the workspace startup time.

Links

UX requirements for a better loading flow: #5231
Parallel pulling of images: #7102
Optimizations in the WS Agent:

Details

Workspace elements to get loaded

Current loading sequence

There are certain elements that needs to be loaded before the user would be fully ready to work on his workspace.

1. Docker Build or Image Pull
This element depends on the workspace's recipe - an image will always be pulled (until it is on our cache) and maybe other docker instructions will be added which will require a Docker Build.

2. Create container
Once the image is there and built, we need to start it and create the workspace's machines (=containers)

3. Install exec agent and start exec agent
The exec agent, is the agent running is the workspace and allowing to instruct commands for execution inside of the workspace's runtime.

4. Install and start terminal agent
The terminal agent, is the one that allows the user to get a terminal in his workspace, for all the machines defined.

5. Start tomcat for ws-agent
This step could be quite long. We download the ws-agent and then starting it. As part of the startup process, there is a tomcat server which is starting inside of the workspace's dev-machine. It load JARs / Java classes and then it provides Project API - which basically allow the user to interact with the project (get the project explorer, open/edit files...)

6. Start other configured agents
If the workspace is requiring other agents to be enabled, those agents will get executed right after ws-agent is started. They will be started sequentially. Each agents, might require dependencies to be downloaded and installed in the workspace runtime.

Once those 6 steps are done, the workspace is considered as fully loaded and ready for the end-user.

Expected UX

The end goal is to allow the user, to browse his files, open some of them - even if everything is not yet started/ready in the workspace's tooling.

With the work on the epic #5231 and #4736 , we will have ability to provide to the user the control on the editor even if all the other tools of the workspace are not yet ready.

Optimizations

Simpler WS Agent

Today, the WS Agent is packaging a lot of different things together. Today, until the whole WS Agent is loaded and started, we can't provide control to the project explorer and the editor. We don't necessarily need all of the components to provide those abilities to the user.

Example:

• Project Type API seems to not be necessary.

The idea would be to simplify and split the WS Agent to extract a "lightweight WS Agent" which will have only the minimum to provide ability to explore projects' files and open files.

Booting sequence

We need to refine the booting sequence so it servers the only goal of providing to the user the ability to interact with the project explorer and open files.

Today, in the loading sequence we first start by installing and starting the exec-agent. This should probably not be the first thing we should do. We should probably directly start the "lightweight WS Agent".

Parallel pulling of images

Today, with the new SPI we are pulling the images, one by one, which makes the loading very slow. A quick improvements can be done by pulling the images in parallel.

Profiling

We need to profile the performances of the elements that are impacting the loading and starting of a workspace. This will help in the identification of potential optimization points.
This work has been started in the following issue: #6169

Lazy loading

Today, we started all the workspace tooling when the workspace is started. But this should not be the case. We should be able to start the tool when the user is actually needing it.

For example:

• A user has activated the JSON LS
• A user is not opening any JSON file --> the JSON LS is not necessary
• A user is opening a JSON file --> the JSON LS would be started at that time

Similarly with SSH and other components.

[sr229]

I have a proposal for Language Servers though, instead of waiting for the file to be opened, why not let it start at the same time the WS Agent starts? It seems painful to wait for the LS to load when it can be lazy-started during WS exec and activate the LS once it opens a file?

[skabashnyuk]

I think we complete all task in this epic. Am I right @slemeur ?

[slemeur]

Yes indeed