Re: [go-nuts] Distributed go testing (running "go test" as a client)

On Tuesday, October 27, 2020 at 10:45:49 AM UTC-7 Ian Lance Taylor wrote: > The linker is definitely slow, though it got faster in 1.15 and will > get faster again in the future 1.16 (I don't know which version you > are running). > We're on go 1.13.1. It's not so much the linker speed I'm co

Re: [go-nuts] Distributed go testing (running "go test" as a client)

On Tue, Oct 27, 2020 at 10:30 AM Craig Silverstein wrote: > > Thanks Ian, that was very helpful. > > It looks like ~50% of the time difference is due to `go vet` calls. I didn't > explore that any further we don't need a vet-run for our use case; I just > disabled it. > > According to my analys

Re: [go-nuts] Distributed go testing (running "go test" as a client)

Thanks Ian, that was very helpful. It looks like ~50% of the time difference is due to `go vet` calls. I didn't explore that any further we don't need a vet-run for our use case; I just disabled it. According to my analysis of the `/usr/bin/time` output, the rest of the time difference is ent

Re: [go-nuts] Distributed go testing (running "go test" as a client)

On Mon, Oct 26, 2020 at 8:46 AM Craig Silverstein wrote: > > > You realize that the flag "-count 1" disable the cache, right? > > Well, it disables *a* cache. The docs don't make it clear, but it > seems like it only disables the test-cache. I don't see why it would > affect the build caches --

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> You realize that the flag "-count 1" disable the cache, right? Well, it disables *a* cache. The docs don't make it clear, but it seems like it only disables the test-cache. I don't see why it would affect the build caches -- build time being my theory as to why the tests are slower. But maybe

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> On 26 Oct 2020, at 10.32, Craig Silverstein wrote: > > > But in my experimenting the overhead of calling `go test` is quite high: > > `go test -count 1 ; go test -count 1 ` is 50% slower than `go > > test -count1 `. > > Oops, I forgot to take parallelism into account. Once I do, it drop

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> But in my experimenting the overhead of calling `go test` is quite high: `go test -count 1 ; go test -count 1 ` is 50% slower than `go test -count1 `. Oops, I forgot to take parallelism into account. Once I do, it drops to 30% slower (which is still significant): % time go test ./pkg/... [

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> On 24 Oct 2020, at 22.21, Craig Silverstein 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` repeated

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> 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. To be clear, I'm not suggesting changing `go test`. My first id

Re: [go-nuts] Distributed go testing (running "go test" as a client)

> On 24 Oct 2020, at 05.57, Craig Silverstein wrote: > > As a way of distributing our go-test run across multiple machines, we are > exploring a client-server architecture. The way we'd like it to work is that > a "go test client" runs on the client machine(s), and repeatedly does the > fol

[go-nuts] Distributed go testing (running "go test" as a client)

As a way of distributing our go-test run across multiple machines, we are exploring a client-server architecture. The way we'd like it to work is that a "go test client" runs on the client machine(s), and repeatedly does the following: 1) make an http GET request to "http:///more_tests"