Hi @Fractal we are sharing your pain 
Our project has over 270 CPP files to build, and it takes 10 times longer to build this (~40 minutes) with the VSCode extension in comparison to 4 minutes with a native cross-compiler build (running in an Ubuntu VirtualBox). It takes the extension about 4 minutes just to perform all its container manipulations to run a debug session, without building anything ! (@matheus.tx can it not wait until after a successful build before deleting the containers on the device ?)
IIUC it is building inside a docker container, inside WSL using an emulator, operate through a bunch of scripts handled by VSCode. So this is no surprise.
On top of that, from time to time, it starts downloading new versions of libraries, which takes an age. Which, I should add, is quite the opposite of our requirements - which are to explicitly control all of the code which our medical application is using. At some point I will have to dig through the various layers of configuration files and scripting to figure out how to control this (see also this).
Whilst these new, fashionable tools are all very exciting to play with, they do not improve anything. In fact my experience so far is significantly worse in comparison with working in QtCreator. The debugger fails on occasion, and in some circumstances my only choice is to reboot Windows FTLOG.
Although the documentation claims that I should be free to concentrate on my code, the truth is quite the opposite. After making a change in my code to test something, it takes so long for the debug code to run, that I have almost forgotten what it was that I was trying. Then sometimes the debugger locks up, and I have to reboot everything.
Frankly, I don’t see containers as adding anything useful for our use-case. They were never designed for running a single application on an embedded device. They are not fit for the purpose. They (probably) impose a extra layer of security, but, imho, this adds significant complications to the code, which are more likely to lead to bugs. The Linux user privilege, which docker relies on, is probably sufficient.
We should be able to develop our application independently from any container. The container should be applied independently, only when the application is deployed, applying the privileges to the container that the application requires. The fact that an application needs to be changed in order to accommodate the container goes to show that the container is not a suitable tool.
Well, perhaps we are an edge case. I suppose not everybody has to provide full control over the system clock.
Sorry for the rant - I hope we can revert to bitbaking our OS from the base-level Torizon in the near future - I think that would suit our overall requirements better…
Tim