vscode-go version: 0.6.88
VSCode recently brought my system to a crawl after doing a find/replace that affected a number of files in a large Go project.
When I was able to get my terminal to respond I found a large number of process running like:
go build -i -o /var/folders/nf/XXXXX/T/go-code-check.164325259 my/packages/here
I had not changed go.buildOnSave, so it would have used the default of package. It appears that since I had saved files from a number of packages simultaneously, this triggered a large number of calls to build those packages which were all running at the same time.
Looking at the code there seem to be two code paths in goBuild that would be affected by this in slightly different ways. When buildWorkspace is true it appears to scan for all packages and then launch the go tool in parallel for all of them. Otherwise for the package case it still appears that goBuild can be called many times concurrently for each file that was saved, leading to a large number of running go processes.
On my system this caused the go processes to use all the available memory. Since they were constantly swapping and competing for resources it took a long time for the system to complete any of the builds.
The process of building the workspace also appears like it will be doing redundant work by invoking go build separately for each package. Typically Go could analyze the package tree to only compile each package once, but by calling it in separate commands this could lead to Go rebuilding dependencies that are shared amongst other packages. The go build command can take a list of packages, so it seems like this should pass all the packages to one invocation of go build.
vscode-go version: 0.6.88
VSCode recently brought my system to a crawl after doing a find/replace that affected a number of files in a large Go project.
When I was able to get my terminal to respond I found a large number of process running like:
I had not changed
go.buildOnSave, so it would have used the default ofpackage. It appears that since I had saved files from a number of packages simultaneously, this triggered a large number of calls to build those packages which were all running at the same time.Looking at the code there seem to be two code paths in
goBuildthat would be affected by this in slightly different ways. WhenbuildWorkspaceis true it appears to scan for all packages and then launch thegotool in parallel for all of them. Otherwise for thepackagecase it still appears thatgoBuildcan be called many times concurrently for each file that was saved, leading to a large number of runninggoprocesses.On my system this caused the
goprocesses to use all the available memory. Since they were constantly swapping and competing for resources it took a long time for the system to complete any of the builds.The process of building the workspace also appears like it will be doing redundant work by invoking
go buildseparately for each package. Typically Go could analyze the package tree to only compile each package once, but by calling it in separate commands this could lead to Go rebuilding dependencies that are shared amongst other packages. Thego buildcommand can take a list of packages, so it seems like this should pass all the packages to one invocation ofgo build.