> But in my experimenting the overhead of calling `go test` is quite high: `go test -count 1 <pkg1>; go test -count 1 <pkg2>` is 50% slower than `go test -count1 <pkg1> <pkg2>`.
Oops, I forgot to take parallelism into account. Once I do, it drops to 30% slower (which is still significant): % time go test ./pkg/... [...] 97.100u 9.512s 0:34.22 311.5% 0+0k 31728+2640816io 79pf+0w % time sh -c 'find pkg -type d | parallel -iFOO go test -count 1 ./FOO' [...] 127.725u 18.722s 0:44.26 330.8% 0+0k 164592+2509424io 443pf+0w I'm curious why it's so much slower to run the tests one at a time than all at once. What work is being redone? -- I'd think anything slow would have been cached. craig On Saturday, October 24, 2020 at 8:46:07 AM UTC-7 Shulhan wrote: > > > > On 24 Oct 2020, at 22.21, Craig Silverstein <csil...@khanacademy.org> > wrote: > > > >> Client: > >> FOR EACH pkg in pkgs DO > >> (1) result := "go test "+ $pkg; > >> (2) POST /$pkg/$result > >> DONE > > > > As I mentioned above: we can certainly do things this way, but there's > > a big performance hit to invoking `go test` repeatedly. > > Oh, I see. Have you try turn off vet doing test? Probably there are other > build/test flags that can also be turned off which I am not aware to > speeding test up. > > > > > To be clear, I'm not suggesting changing `go test`. My first idea was > > to write our own tool, that calls out to the API in > > https://golang.org/pkg/testing/ to do the actual mechanics of testing. > > But that API doesn't seem to be designed to allow such a thing -- as > > one example, the `go test` commandline tool seems to do a lot of work > > itself, that our tool would need to duplicate -- and it's unclear how > > practical it is to force it. There may well be better ideas we don't > > know enough to even think of, though. > > Another solution that I can think of is by building each package tests > binaries in server and distributed it to test machines, so the client does > not need to re-build (file read/write, compile, linking, and so on). > > -- > Shulhan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3e4721f7-5543-475c-be9c-1603f8d14908n%40googlegroups.com.