I got curious about the first step, since I also see this in a build in another project. It spends almost the entirety of the time hashing some files, apparently. Hashing is not surprising for a build system, it is completely natural behavior. The time spent here however is!

My first thoughts were: can we make this faster? Run in parallel? There are two operations here, are they maybe hashing the same files and we can save half the work? -- But those are the wrong questions to ask.

The right question to ask is this: This is a warm build. There are no I/O stalls. 25s is an eternity, and this sample is still a comparatively small game. What tens of gigabytes of data are we even hashing here?

So I put a cache into the hashing and hash every file we see exactly once. I clear the cache at the very beginning of the build, then use it for all build steps. The cache keeps track of what's requested. We are hashing the same file 19922 times, and not much else.

Lo and behold, with the cache in place I now had to zoom in to even find these steps: the time dropped to 800ms, from 25.5s. The hashing is about 2ms, the rest is different overhead.

The lesson here is that you should always look at the data and ask "is this reasonable?"

Another insight is the by now old-news that @superluminal is awesome because it has mixed callstack support for Unity.