have you ruled out your antivirus being responsible for the slowness

have you ruled out your antivirus being responsible for the slowness

This is an interesting hypothesis. I do have a Trendmicro installed, and I am sometimes asked to trust the built executable.

But how can I detect that the build slowness is due to the antivirus, especially not in the compilation but in the load module phase?
I am aware the antivirus is constantly running in the background, but since my laptop has 4 cores, I always have around 80% of CPU available to me according to Windows task manager.
Is there a known pathway for the antivirus to affect exclusively the load module phase rather than the CPU intensive actual compilation phase?
What makes the load module phase so special?

it downloads and opens a lot of files, antivirus may want to scan those as untrusted content.

it downloads and opens a lot of files, antivirus may want to scan those as untrusted content.

This is an interesting hypothesis. Alas, I am on a corporate computer, and thus can't do much about the antivirus.
However, I would like to note that on the same computer, I can read 500MB in 300ms from disk, so whatever the antivirus is interfering with IO operations, it may be neglibible?

I do notice something special in the traces, there are large gaps between the modfetch.download phase:

For example, there's a large gap of 6 seconds between:

• modfetch.download golang.org/x/text@v0.3.8, start time 13s 226ms, duration 834us
• modfetch.download golang.org/x/image, start time 19s 444ms, duration 1ms 247us

I wonder what is the cause of these seamingly doing nothing gaps?
Since I can build without internet connection, I presume modfetch.download should be no-ops, and thus the antivirus should not be in the loop. Am I missing something?

I assume it's still opening a lot of files (which may be checked) in that time, even if it doesn't have to download them from the internet.
Or you have a slow filesystem (lots of small reads has a different performance profile than one big sequential read).

Interestingly, the build is fast when building from the vendor folder!
As shown in the trace below, load.PackagesAndErrors now takes only 8s, as opposed to the 32s in the normal build:

trace.zip

What this means, is that there's nothing wrong with my computer, and that go builds can be fast. Indeed, except recently Go builds have always been fast, and this snappiness regardless of machine, platform or program size, is why I love Go so much for so many years since before Go 1.0.

Alas, there's still room for improvement, as can be seen in the trace above, there's a mysterious 6s second gap in the very beginning before load.PackagesAndErrors does it first thing modload.loadImport bytes.
Why this gap? Without this seemingly doing nothing gap, load.PackagesAndErrors actually takes only 2s, and the overall build sould be able to complete in 4s, a 10x improvement over the original 40s!!!
How can we get further granularity of what's going on inside load.PackagesAndErrors? What can be done to eliminate all do nothing gaps in go build entirely?

P.S. the exact steps for building with the vendor directory is:

go mod vendor  # copy source files of all dependacies into the vendor subfolder.
go build cmd\server\GoServer.go  # build as usual.

you can build and run a modified tool chain with more detailed trace spans covering the parts that you think are interesting.