Uwe Dauernheim

Should be doable, testing might be trickier. I guess there are more testable and tolerable states: port bound > server up and accept > server up and accept only pass...

You mean like a "reverse" feature? Sounds fun!

We have 46 instances and have 69s. It's of course not ran often, but would still be nice to do it faster. Mostly each mock generation should be able to...

Yes, saw the golang issue, but that doesn't seem to go anyway due to philosophy or constraint guarantees. The idea here is to just not use `moq` with `go generate`...

Also: I'm quite sure `go generate` itself is fast, so `moq` must take 69s/46 ~ 1.5s per mock generation which, if assumption is right, can't see as optimal.

Some numbers from a 2.3GHz i9 8-Core macbook: ``` $ find . -name '*_mock.go' -delete ; time go generate ./... 1.34 real 5.44 user 1.06 sys 0.65 real 2.54 user...

Also no significant changes with `-skip-ensure` or `-fmt noop`: ``` go generate ./... 208.86s user 40.56s system 523% cpu 47.619 total go generate ./... 193.61s user 38.79s system 530% cpu...

I am doing the parallel part currently with a script, but yes, it has a few tradeoffs and less elegance. As an exercise for the reader I will try to...

# Approach 1: Performance > My assumption is, that loading the package information ( > > https://github.com/matryer/moq/blob/13aa0482dc83d813df2ae11a107bf1f697298d09/internal/registry/registry.go#L130 > > ) is the most expensive part, especially if `moq` is used...

Is this issue still of interest?