FAQ
I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.

This is the code I used:

-----------------------

package main
import (
"fmt"
"time"
)
func fib(n int) int {
if n < 1 {
return 0
} else if n <= 2 {
return 1
}
return fib(n - 1) + fib(n - 2)
}
func main() {
start := time.Now()

// Magical int that changes build times
n := 35

r := fib(n)
fmt.Printf("fib(%v) == %v, time: %v\n", n, r, time.Since(start))
}

--------------------------

This is the described result of timing builds (going from 5 to 35 midway
through):

After discussions in #go-nuts we figured out that it's the linker (8l.exe)
that seems to be the culprit, as 8g takes 0.020s no matter what n is.

So, could someone explain this build time growth? I'm running Windows 7
with Go-devel built from source as recent as yesterday.

--

## Search Discussions

•  at Sep 24, 2012 at 3:19 am ⇧

On Monday, 24 September 2012 10:36:01 UTC+10, darkgray wrote:

So, could someone explain this build time growth? ...
I do not understand what your problem is. Please, provide steps I can
follow to reproduce your issue and I will investigate. You should use
you.

Alex

--
•  at Sep 24, 2012 at 5:14 pm ⇧
Wild-Ass Guess: Does the runtime change based on n? I wonder if the linker
is trying to do constant folding and actually running your fib() code or
something ...
On Sunday, September 23, 2012 8:36:01 PM UTC-4, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.

This is the code I used:

-----------------------

package main
import (
"fmt"
"time"
)
func fib(n int) int {
if n < 1 {
return 0
} else if n <= 2 {
return 1
}
return fib(n - 1) + fib(n - 2)
}
func main() {
start := time.Now()

// Magical int that changes build times
n := 35

r := fib(n)
fmt.Printf("fib(%v) == %v, time: %v\n", n, r, time.Since(start))
}

--------------------------

This is the described result of timing builds (going from 5 to 35 midway
through):

After discussions in #go-nuts we figured out that it's the linker (8l.exe)
that seems to be the culprit, as 8g takes 0.020s no matter what n is.

So, could someone explain this build time growth? I'm running Windows 7
with Go-devel built from source as recent as yesterday.
--
•  at Sep 24, 2012 at 4:52 pm ⇧

On Tuesday, September 25, 2012, Larry Clapp wrote:

Wild-Ass Guess: Does the runtime change based on n? I wonder if the
linker is trying to do constant folding and actually running your fib()
code or something ...
No, the linker won't do that.
--
•  at Sep 24, 2012 at 5:14 pm ⇧
I am very relieved to tell you that I cannot reproduce this. Do you
get different output on your machine? Do the binaries get bigger?

\$ cd
go run x.go
0 0.024 0.157
1 0.024 0.156
2 0.025 0.158
3 0.024 0.154
4 0.024 0.153
5 0.025 0.153
6 0.024 0.155
7 0.025 0.153
8 0.025 0.156
9 0.024 0.155
10 0.024 0.152
11 0.024 0.154
12 0.025 0.153
13 0.025 0.157
14 0.024 0.156
15 0.024 0.156
16 0.024 0.157
17 0.025 0.152
18 0.024 0.154
19 0.025 0.156
20 0.024 0.158
21 0.025 0.154
22 0.024 0.153
23 0.025 0.153
24 0.024 0.156
25 0.024 0.156
26 0.024 0.153
27 0.024 0.155
28 0.025 0.155
29 0.025 0.153
30 0.024 0.156
31 0.024 0.154
32 0.024 0.152
33 0.024 0.153
34 0.025 0.154
35 0.024 0.155
36 0.024 0.154
37 0.025 0.153
38 0.024 0.154
39 0.025 0.154
40 0.025 0.157
\$ GOARCH=386 go run x.go
0 0.025 0.169
1 0.024 0.168
2 0.024 0.166
3 0.024 0.165
4 0.024 0.165
5 0.024 0.165
6 0.025 0.165
7 0.024 0.166
8 0.024 0.167
9 0.024 0.165
10 0.025 0.165
11 0.024 0.164
12 0.025 0.170
13 0.024 0.168
14 0.025 0.165
15 0.024 0.165
16 0.024 0.165
17 0.024 0.165
18 0.024 0.168
19 0.024 0.166
20 0.024 0.164
21 0.024 0.165
22 0.024 0.165
23 0.024 0.167
24 0.024 0.166
25 0.025 0.167
26 0.024 0.165
27 0.024 0.165
28 0.025 0.164
29 0.024 0.166
30 0.025 0.165
31 0.024 0.165
32 0.024 0.165
33 0.025 0.164
34 0.025 0.168
35 0.024 0.166
36 0.025 0.165
37 0.024 0.166
38 0.025 0.164
39 0.024 0.168
40 0.024 0.165
\$ cat x.go
package main

import (
"fmt"
"io/ioutil"
"log"
"runtime"
"os/exec"
"strings"
"time"
)

func main() {
ch := "6"
if runtime.GOARCH == "386" {
ch = "8"
}

for i := 0; i <= 40; i++ {
prog := strings.Replace(prog, "NNN", fmt.Sprint(i), -1)
if err := ioutil.WriteFile("/tmp/x.go", []byte(prog), 0666); err != nil {
log.Fatal(err)
}
t1 := time.Now()
out, err := exec.Command("go", "tool", ch+"g", "-o", "/tmp/x.o",
"/tmp/x.go").CombinedOutput()
if err != nil {
log.Fatalf("%s\n%s", err, out)
}
dt1 := time.Since(t1)
t2 := time.Now()
out, err = exec.Command("go", "tool", ch+"l", "-o", "/tmp/x.o1",
"/tmp/x.o").CombinedOutput()
if err != nil {
log.Fatalf("%s\n%s", err, out)
}
dt2 := time.Since(t2)

fmt.Printf("%d %.3f %.3f\n", i, dt1.Seconds(), dt2.Seconds())
}
}

const prog = `package main

import (
"fmt"
"time"
)

func fib(n int) int {
if n < 1 {
return 0
} else if n <= 2 {
return 1
}
return fib(n - 1) + fib(n - 2)
}

func main() {
start := time.Now()

// Magical int that changes build times
n := NNN

r := fib(n)
fmt.Printf("fib(%v) == %v, time: %v\n", n, r, time.Since(start))
}
`
\$

--
•  at Sep 24, 2012 at 5:21 pm ⇧
that the build times were constant for go1.0.2 but varied on tip. when
dug deeper, it was confirmed that the linker produced varied builds:

18:01 8g seems to take 0.020s for either file.
18:02 8l -o test.exe test.8:
18:02 0.205s to 0.468s with n=5.
18:03 1.627s to 1.647s with n=35.

binary size:

18:11 n=35.exe is 1383kb, n=5.exe is 1383kb

no difference in build times for go1.0.2:

18:34 My bin installation of 1.0.2 takes 0.254s to build it.
18:34 And doesn't care at all about n.

I believe this was all done on a windows 7 machine.

--
•  at Sep 24, 2012 at 6:33 pm ⇧
Output:

darkgray@PEARL ~/Documents/go
\$ go run x.go
0 0.054 0.361
1 0.049 0.387
2 0.049 0.380
3 0.050 0.380
4 0.049 0.378
5 0.049 0.383
6 0.049 0.375
7 0.050 0.386
8 0.049 0.381
9 0.050 0.376
10 0.049 0.380
11 0.049 0.419
12 0.049 0.380
13 0.051 0.389
14 0.049 0.388
15 0.050 0.385
16 0.050 0.375
17 0.049 0.224
18 0.049 0.384
19 0.050 0.386
20 0.049 0.384
21 0.049 0.381
22 0.049 0.384
23 0.050 0.386
24 0.050 0.420
25 0.049 0.406
26 0.049 0.430
27 0.049 0.460
28 0.049 0.606
29 0.049 0.596
30 0.050 0.724
31 0.050 0.943
32 0.050 1.291
33 0.049 1.657
34 0.049 1.663
35 0.050 1.668
36 0.049 1.660
37 0.050 1.661
38 0.049 1.663
39 0.049 1.655
40 0.050 1.669

As mentioned above, the executable is always 1383kb (even with n=360 tested
for fun). My 64bit bin installation of 1.0.2 doesn't show this peculiar
behaviour. I don't know if it's the result of a broken mingw or what.

On Monday, 24 September 2012 19:07:29 UTC+2, Russ Cox wrote:

I am very relieved to tell you that I cannot reproduce this. Do you
get different output on your machine? Do the binaries get bigger?

\$ cd
go run x.go
0 0.024 0.157
1 0.024 0.156
2 0.025 0.158
3 0.024 0.154
4 0.024 0.153
5 0.025 0.153
6 0.024 0.155
7 0.025 0.153
8 0.025 0.156
9 0.024 0.155
10 0.024 0.152
11 0.024 0.154
12 0.025 0.153
13 0.025 0.157
14 0.024 0.156
15 0.024 0.156
16 0.024 0.157
17 0.025 0.152
18 0.024 0.154
19 0.025 0.156
20 0.024 0.158
21 0.025 0.154
22 0.024 0.153
23 0.025 0.153
24 0.024 0.156
25 0.024 0.156
26 0.024 0.153
27 0.024 0.155
28 0.025 0.155
29 0.025 0.153
30 0.024 0.156
31 0.024 0.154
32 0.024 0.152
33 0.024 0.153
34 0.025 0.154
35 0.024 0.155
36 0.024 0.154
37 0.025 0.153
38 0.024 0.154
39 0.025 0.154
40 0.025 0.157
\$ GOARCH=386 go run x.go
0 0.025 0.169
1 0.024 0.168
2 0.024 0.166
3 0.024 0.165
4 0.024 0.165
5 0.024 0.165
6 0.025 0.165
7 0.024 0.166
8 0.024 0.167
9 0.024 0.165
10 0.025 0.165
11 0.024 0.164
12 0.025 0.170
13 0.024 0.168
14 0.025 0.165
15 0.024 0.165
16 0.024 0.165
17 0.024 0.165
18 0.024 0.168
19 0.024 0.166
20 0.024 0.164
21 0.024 0.165
22 0.024 0.165
23 0.024 0.167
24 0.024 0.166
25 0.025 0.167
26 0.024 0.165
27 0.024 0.165
28 0.025 0.164
29 0.024 0.166
30 0.025 0.165
31 0.024 0.165
32 0.024 0.165
33 0.025 0.164
34 0.025 0.168
35 0.024 0.166
36 0.025 0.165
37 0.024 0.166
38 0.025 0.164
39 0.024 0.168
40 0.024 0.165
\$ cat x.go
package main

import (
"fmt"
"io/ioutil"
"log"
"runtime"
"os/exec"
"strings"
"time"
)

func main() {
ch := "6"
if runtime.GOARCH == "386" {
ch = "8"
}

for i := 0; i <= 40; i++ {
prog := strings.Replace(prog, "NNN", fmt.Sprint(i), -1)
if err := ioutil.WriteFile("/tmp/x.go", []byte(prog),
0666); err != nil {
log.Fatal(err)
}
t1 := time.Now()
out, err := exec.Command("go", "tool", ch+"g", "-o",
"/tmp/x.o",
"/tmp/x.go").CombinedOutput()
if err != nil {
log.Fatalf("%s\n%s", err, out)
}
dt1 := time.Since(t1)
t2 := time.Now()
out, err = exec.Command("go", "tool", ch+"l", "-o",
"/tmp/x.o1",
"/tmp/x.o").CombinedOutput()
if err != nil {
log.Fatalf("%s\n%s", err, out)
}
dt2 := time.Since(t2)

fmt.Printf("%d %.3f %.3f\n", i, dt1.Seconds(),
dt2.Seconds())
}
}

const prog = `package main

import (
"fmt"
"time"
)

func fib(n int) int {
if n < 1 {
return 0
} else if n <= 2 {
return 1
}
return fib(n - 1) + fib(n - 2)
}

func main() {
start := time.Now()

// Magical int that changes build times
n := NNN

r := fib(n)
fmt.Printf("fib(%v) == %v, time: %v\n", n, r, time.Since(start))
}
`
\$
--
•  at Sep 24, 2012 at 9:13 pm ⇧

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:
I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.
[...]

If there is such a tool as strace on Windows, you could run that to perhaps
get some idea how the linker is interacting with the system. Another,
possibly long shot is that you have an anti-virus etc. program that's
interfering

--
•  at Sep 24, 2012 at 7:23 pm ⇧
What happens if you run the sequence in reverse? Do the builds from 40 to 1 start slow and speed up?
On 25/09/2012, at 5:20, DisposaBoy wrote:

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and noticed that the go build times for my program were fluctuating wildly with very minor changes to the code. Running go build would take an average of 0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out at about 1.75s for n>35. This was the only change made, and I've run loops to time builds ten times for a bunch of values of n.
[...]
If there is such a tool as strace on Windows, you could run that to perhaps get some idea how the linker is interacting with the system. Another, possibly long shot is that you have an anti-virus etc. program that's interfering

--
--
•  at Sep 24, 2012 at 9:28 pm ⇧
Er, I guess the mystery is solved.

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.053 1.668
39 0.050 1.653
38 0.049 1.650
37 0.049 1.654
36 0.049 1.651
35 0.049 1.646
34 0.049 1.650
33 0.049 1.650
32 0.049 1.280
31 0.049 0.944
30 0.049 0.732
29 0.049 0.590
28 0.049 0.532
27 0.050 0.464
26 0.049 0.438
25 0.049 0.417
24 0.049 0.401
23 0.049 0.387
22 0.049 0.387
21 0.049 0.389
20 0.049 0.390
19 0.050 0.389
18 0.049 0.384
17 0.049 0.377
16 0.049 0.385
15 0.049 0.385
14 0.049 0.381
13 0.049 0.392
12 0.051 0.462
11 0.049 0.395
10 0.049 0.384
9 0.049 0.379
8 0.049 0.378
7 0.049 0.377
6 0.049 0.385
5 0.048 0.382
4 0.050 0.380
3 0.049 0.376
2 0.049 0.384
1 0.049 0.383
0 0.049 0.388

---
Tried turning off Microsoft Security Essentials realtime protection here.
---

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.047 0.222
39 0.048 0.235
38 0.048 0.236
37 0.048 0.228
36 0.047 0.245
35 0.048 0.241
34 0.047 0.229
33 0.047 0.225
32 0.047 0.225
31 0.048 0.225
30 0.047 0.222
29 0.047 0.237
28 0.048 0.219
27 0.048 0.286
26 0.048 0.221
25 0.047 0.218
24 0.048 0.223
23 0.047 0.226
22 0.047 0.233
21 0.047 0.226
20 0.048 0.228
19 0.048 0.220
18 0.047 0.233
17 0.047 0.226
16 0.050 0.233
15 0.047 0.226
14 0.049 0.280
13 0.047 0.225
12 0.047 0.229
11 0.048 0.226
10 0.047 0.221
9 0.047 0.220
8 0.048 0.225
7 0.047 0.224
6 0.047 0.218
5 0.047 0.226
4 0.048 0.222
3 0.047 0.225
2 0.047 0.221
1 0.047 0.225
0 0.047 0.227

So, well, I guess it's Security Essentials that's been slowing down the
linker. I've no clue why the int matters, or why it only happens with this
particular Go version, but uh.

On Monday, 24 September 2012 21:20:16 UTC+2, DisposaBoy wrote:

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.
[...]

If there is such a tool as strace on Windows, you could run that to
perhaps get some idea how the linker is interacting with the system.
Another, possibly long shot is that you have an anti-virus etc. program
that's interfering
--
•  at Sep 24, 2012 at 9:54 pm ⇧
Amazing.
On Tue, Sep 25, 2012 at 2:50 AM, darkgray wrote:
Er, I guess the mystery is solved.

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.053 1.668
39 0.050 1.653
38 0.049 1.650
37 0.049 1.654
36 0.049 1.651
35 0.049 1.646
34 0.049 1.650
33 0.049 1.650
32 0.049 1.280
31 0.049 0.944
30 0.049 0.732
29 0.049 0.590
28 0.049 0.532
27 0.050 0.464
26 0.049 0.438
25 0.049 0.417
24 0.049 0.401
23 0.049 0.387
22 0.049 0.387
21 0.049 0.389
20 0.049 0.390
19 0.050 0.389
18 0.049 0.384
17 0.049 0.377
16 0.049 0.385
15 0.049 0.385
14 0.049 0.381
13 0.049 0.392
12 0.051 0.462
11 0.049 0.395
10 0.049 0.384
9 0.049 0.379
8 0.049 0.378
7 0.049 0.377
6 0.049 0.385
5 0.048 0.382
4 0.050 0.380
3 0.049 0.376
2 0.049 0.384
1 0.049 0.383
0 0.049 0.388

---
Tried turning off Microsoft Security Essentials realtime protection here.
---

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.047 0.222
39 0.048 0.235
38 0.048 0.236
37 0.048 0.228
36 0.047 0.245
35 0.048 0.241
34 0.047 0.229
33 0.047 0.225
32 0.047 0.225
31 0.048 0.225
30 0.047 0.222
29 0.047 0.237
28 0.048 0.219
27 0.048 0.286
26 0.048 0.221
25 0.047 0.218
24 0.048 0.223
23 0.047 0.226
22 0.047 0.233
21 0.047 0.226
20 0.048 0.228
19 0.048 0.220
18 0.047 0.233
17 0.047 0.226
16 0.050 0.233
15 0.047 0.226
14 0.049 0.280
13 0.047 0.225
12 0.047 0.229
11 0.048 0.226
10 0.047 0.221
9 0.047 0.220
8 0.048 0.225
7 0.047 0.224
6 0.047 0.218
5 0.047 0.226
4 0.048 0.222
3 0.047 0.225
2 0.047 0.221
1 0.047 0.225
0 0.047 0.227

So, well, I guess it's Security Essentials that's been slowing down the
linker. I've no clue why the int matters, or why it only happens with this
particular Go version, but uh.

On Monday, 24 September 2012 21:20:16 UTC+2, DisposaBoy wrote:

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.
[...]

If there is such a tool as strace on Windows, you could run that to
perhaps get some idea how the linker is interacting with the system.
Another, possibly long shot is that you have an anti-virus etc. program
that's interfering
--

--
650-335-5765

--
•  at Sep 24, 2012 at 10:37 pm ⇧
it should be called nonlinear-time protection :)

out of curiosity, with "protection" turned on, does it make a
difference where the binary comes from? (i.e. locally built or
On Mon, Sep 24, 2012 at 2:20 PM, darkgray wrote:
Er, I guess the mystery is solved.

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.053 1.668
39 0.050 1.653
38 0.049 1.650
37 0.049 1.654
36 0.049 1.651
35 0.049 1.646
34 0.049 1.650
33 0.049 1.650
32 0.049 1.280
31 0.049 0.944
30 0.049 0.732
29 0.049 0.590
28 0.049 0.532
27 0.050 0.464
26 0.049 0.438
25 0.049 0.417
24 0.049 0.401
23 0.049 0.387
22 0.049 0.387
21 0.049 0.389
20 0.049 0.390
19 0.050 0.389
18 0.049 0.384
17 0.049 0.377
16 0.049 0.385
15 0.049 0.385
14 0.049 0.381
13 0.049 0.392
12 0.051 0.462
11 0.049 0.395
10 0.049 0.384
9 0.049 0.379
8 0.049 0.378
7 0.049 0.377
6 0.049 0.385
5 0.048 0.382
4 0.050 0.380
3 0.049 0.376
2 0.049 0.384
1 0.049 0.383
0 0.049 0.388

---
Tried turning off Microsoft Security Essentials realtime protection here.
---

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.047 0.222
39 0.048 0.235
38 0.048 0.236
37 0.048 0.228
36 0.047 0.245
35 0.048 0.241
34 0.047 0.229
33 0.047 0.225
32 0.047 0.225
31 0.048 0.225
30 0.047 0.222
29 0.047 0.237
28 0.048 0.219
27 0.048 0.286
26 0.048 0.221
25 0.047 0.218
24 0.048 0.223
23 0.047 0.226
22 0.047 0.233
21 0.047 0.226
20 0.048 0.228
19 0.048 0.220
18 0.047 0.233
17 0.047 0.226
16 0.050 0.233
15 0.047 0.226
14 0.049 0.280
13 0.047 0.225
12 0.047 0.229
11 0.048 0.226
10 0.047 0.221
9 0.047 0.220
8 0.048 0.225
7 0.047 0.224
6 0.047 0.218
5 0.047 0.226
4 0.048 0.222
3 0.047 0.225
2 0.047 0.221
1 0.047 0.225
0 0.047 0.227

So, well, I guess it's Security Essentials that's been slowing down the
linker. I've no clue why the int matters, or why it only happens with this
particular Go version, but uh.

On Monday, 24 September 2012 21:20:16 UTC+2, DisposaBoy wrote:

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly with
very minor changes to the code. Running go build would take an average of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and plane out
at about 1.75s for n>35. This was the only change made, and I've run loops
to time builds ten times for a bunch of values of n.
[...]

If there is such a tool as strace on Windows, you could run that to
perhaps get some idea how the linker is interacting with the system.
Another, possibly long shot is that you have an anti-virus etc. program
that's interfering
--
--
•  at Sep 24, 2012 at 10:34 pm ⇧
I'm not entirely sure. The wonky behaviour was observed using a locally
1.0.2 (and later 1.0.3) had a constant build time in spite of Security
Essentials running.

On Tuesday, 25 September 2012 00:30:44 UTC+2, Skip wrote:

it should be called nonlinear-time protection :)

out of curiosity, with "protection" turned on, does it make a
difference where the binary comes from? (i.e. locally built or

On Mon, Sep 24, 2012 at 2:20 PM, darkgray <dark...@gmail.com <javascript:>>
wrote:
Er, I guess the mystery is solved.

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.053 1.668
39 0.050 1.653
38 0.049 1.650
37 0.049 1.654
36 0.049 1.651
35 0.049 1.646
34 0.049 1.650
33 0.049 1.650
32 0.049 1.280
31 0.049 0.944
30 0.049 0.732
29 0.049 0.590
28 0.049 0.532
27 0.050 0.464
26 0.049 0.438
25 0.049 0.417
24 0.049 0.401
23 0.049 0.387
22 0.049 0.387
21 0.049 0.389
20 0.049 0.390
19 0.050 0.389
18 0.049 0.384
17 0.049 0.377
16 0.049 0.385
15 0.049 0.385
14 0.049 0.381
13 0.049 0.392
12 0.051 0.462
11 0.049 0.395
10 0.049 0.384
9 0.049 0.379
8 0.049 0.378
7 0.049 0.377
6 0.049 0.385
5 0.048 0.382
4 0.050 0.380
3 0.049 0.376
2 0.049 0.384
1 0.049 0.383
0 0.049 0.388

---
Tried turning off Microsoft Security Essentials realtime protection here.
---

darkgray@PEARL ~/Documen
\$ go run x.go
40 0.047 0.222
39 0.048 0.235
38 0.048 0.236
37 0.048 0.228
36 0.047 0.245
35 0.048 0.241
34 0.047 0.229
33 0.047 0.225
32 0.047 0.225
31 0.048 0.225
30 0.047 0.222
29 0.047 0.237
28 0.048 0.219
27 0.048 0.286
26 0.048 0.221
25 0.047 0.218
24 0.048 0.223
23 0.047 0.226
22 0.047 0.233
21 0.047 0.226
20 0.048 0.228
19 0.048 0.220
18 0.047 0.233
17 0.047 0.226
16 0.050 0.233
15 0.047 0.226
14 0.049 0.280
13 0.047 0.225
12 0.047 0.229
11 0.048 0.226
10 0.047 0.221
9 0.047 0.220
8 0.048 0.225
7 0.047 0.224
6 0.047 0.218
5 0.047 0.226
4 0.048 0.222
3 0.047 0.225
2 0.047 0.221
1 0.047 0.225
0 0.047 0.227

So, well, I guess it's Security Essentials that's been slowing down the
linker. I've no clue why the int matters, or why it only happens with this
particular Go version, but uh.

On Monday, 24 September 2012 21:20:16 UTC+2, DisposaBoy wrote:

On Monday, September 24, 2012 1:36:01 AM UTC+1, darkgray wrote:

I was fiddling with an incredibly naive Fibonacci number generator and
noticed that the go build times for my program were fluctuating wildly
with
very minor changes to the code. Running go build would take an average
of
0.4s when int n was set to 5, and then grow to 0.8s for n=25, and
plane out
at about 1.75s for n>35. This was the only change made, and I've run
loops
to time builds ten times for a bunch of values of n.
[...]

If there is such a tool as strace on Windows, you could run that to
perhaps get some idea how the linker is interacting with the system.
Another, possibly long shot is that you have an anti-virus etc. program
that's interfering
--
--
•  at Sep 25, 2012 at 6:53 am ⇧
I may be wrong but IIRC the official builds are signed. in the past they were being flagged or something so whatever was done to resolve that could be the difference between the official builds and your local builds

--
•  at Sep 25, 2012 at 3:29 pm ⇧

On Tuesday, September 25, 2012, DisposaBoy wrote:

I may be wrong but IIRC the official builds are signed. in the past they
were being flagged or something
No, they are not signed at least for 1.0.3.
Andrew (adg) once said that he'd like to use Google's key to sign
the Mac OS X .pkg, but due to time constraint, he couldn't make
it approved in time for Go 1.0.3, so he instead released .tar.gz for
Mac OS X.

FYI, newest Mac OS X doesn't allow unsigned .pkg to be installed
by default.

--

## Related Discussions

Discussion Overview
 group golang-nuts categories go posted Sep 24, '12 at 1:43a active Sep 25, '12 at 3:29p posts 15 users 10 website golang.org

### 10 users in discussion

Content

People

Support

Translate

site design / logo © 2021 Grokbase