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
ounts
for almost all the difference in the test-run times. I don't know what to
make of that though.
craig
On Monday, October 26, 2020 at 10:04:27 PM UTC-7 Ian Lance Taylor wrote:
> On Mon, Oct 26, 2020 at 8:46 AM Craig Silverstein
> wrote:
> >
> > > You realiz
tests are slower. But maybe it does? Or maybe the extra time isn't
being spent in building after all.
> Also, why not using the "-p" flag if you want it to be parallel?
I should have done!
craig
On Mon, Oct 26, 2020 at 4:16 AM Shulhan wrote:
>
>
>
> >
han 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
> wrote:
> >
> >> 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
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"
