chore: make fiximports run in parallel

[rvagg]

fiximports has been driving me a little insane lately. For some reason it's started taking up to ~40s each execution and I can't figure out why. I tried switched from running go from a snap to just installing it from a package, I tried clearing my go build cache, I tried removing all the x/tools sources I had. Maybe I made a difference somewhere in there, but I'm still ~20s.

When measuring, the time cost is all in imports.Process, so something in there isn't having a happy time.

After a couple of iterations of trying to fix it I've landed on the following approach which gives me the best results:

1. Find all of the files we need to process
2. Read all file contents in (+ do the quick imports newline squash)
3. For each mutation of imports.LocalPrefix, process all files in parallel—so we still do imports.Process twice but we do the files in parallel and don't need to worry about imports.LocalPrefix mutation
4. Write out any files that have been changed

Before:

$ time make fiximports 
go run ./scripts/fiximports

real    0m20.004s
user    0m15.952s
sys     0m12.062s

After:

$ time make fiximports 
go run ./scripts/fiximports

real    0m1.859s
user    0m16.487s
sys     0m16.172s

Almost too good to be true? Seems to work just fine though. @masih would you mind taking a good look at this when you have some time please?

[Copilot]

Pull Request Overview

This PR refactors the fiximports script to improve performance by processing files in parallel.

• Introduces concurrent reading, processing, and writing of file contents.
• Replaces the sequential fixGoImports function with parallel pipelines using worker routines.

[masih]

Seen #11695 (comment) ?

[rvagg]

No, but

I think the thing to do is to simplify our formatting to two groups of SDK and no SDK

Yes, that was my initial thought as I was working on this because it's that global that stops simple parallelism. Figured I'd try for least-change though and this yields pretty good results.

[masih]

No blockers.

I think the logic can be simplified quite a bit using error groups.

[rvagg]

Yeah, errgroups made it much better, thanks. PTAL @masih

[Copilot]

Pull Request Overview

This PR addresses the performance issues in the fiximports tool by processing files in parallel. Key changes include:

• Reading file contents concurrently before processing.
• Using parallel execution to run imports.Process for multiple prefixes.
• Writing modified files concurrently after processing.

[Copilot]

Pull Request Overview

This PR aims to significantly reduce the execution time of fiximports by processing files in parallel, reducing the overall runtime drastically.

• Converts file reading, processing, and writing to parallel operations.
• Leverages errgroup with a worker limit based on the number of CPUs.