> 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.

Reply via email to