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):


<https://lh4.googleusercontent.com/-r2PuAI0MKgM/UF-p3-fRraI/AAAAAAAAA4w/aTF78jh3yxI/s1600/Clipboard01.jpg>
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

  • Brainman 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
    http://code.google.com/p/go/issues to keep progress of your issue. Thank
    you.

    Alex

    --
  • Larry Clapp 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):



    <https://lh4.googleusercontent.com/-r2PuAI0MKgM/UF-p3-fRraI/AAAAAAAAA4w/aTF78jh3yxI/s1600/Clipboard01.jpg>
    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.
    --
  • Minux 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.
    --
  • Russ Cox 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))
    }
    `
    $

    --
  • Andrey mirtchovski at Sep 24, 2012 at 5:21 pm
    here's some more information from irc. the original author reported
    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.

    --
  • Darkgray 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))
    }
    `
    $
    --
  • DisposaBoy 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


    --
  • Dave Cheney 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

    --
    --
  • Darkgray 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
    --
  • Michael Jones 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
    --


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
  • Skip Tavakkolian 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
    downloaded)
    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
    --
    --
  • Darkgray at Sep 24, 2012 at 10:34 pm
    I'm not entirely sure. The wonky behaviour was observed using a locally
    built-from-source tip version of Go, but my downloaded-and-installed binary
    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
    downloaded)

    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
    --
    --
  • DisposaBoy 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

    --
  • Minux 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 Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 24, '12 at 1:43a
activeSep 25, '12 at 3:29p
posts15
users10
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase