FAQ
I was writing code involving a lot of slice loops. First I used index
variables, but then found this form more convenient:

http://play.golang.org/p/ygdN3vVywE

Question: Does it matter at all, or can I assume loops like this are well
optimized by the compiler?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Itmitica at Mar 2, 2013 at 8:13 pm
    An index i is cheaper, versus a slice copy i, and I'd say that for big
    slices, it would actually matter.
    http://play.golang.org/p/hMIqagp7Gv

    Mitică

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Mar 2, 2013 at 8:20 pm
    All slice values are the same size, 1 uintptr + 2 int.
    On 03/03/2013, at 6:44 AM, "itmitica@gmail.com" wrote:

    An index i is cheaper, versus a slice copy i, and I'd say that for big slices, it would actually matter.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Mar 2, 2013 at 8:25 pm

    On 2013/3/2 wrote:
    An index i is cheaper, versus a slice copy i, and I'd say that for big
    slices, it would actually matter.
    http://play.golang.org/p/hMIqagp7Gv

    Mitică
    I see similar performance here (even in favour of the reslicing
    trick): (inlining is disabled in benchmarks)

    go1
    BenchmarkIndex 10000000 162 ns/op
    BenchmarkSlice 10000000 156 ns/op

    go1.1
    BenchmarkIndex 10000000 137 ns/op
    BenchmarkSlice 20000000 132 ns/op

    package main

    import (
    "testing"
    )

    func use(s []byte) {}

    func BenchmarkIndex(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := 0; i <= len(s); i++ {
    use(s[i:])
    }
    }
    }

    func BenchmarkSlice(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := s; len(i) > 0; i = i[1:] {
    use(i)
    }
    }
    }

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • peterGo at Mar 3, 2013 at 12:57 am
    Rémy,

    Why not use a range clause?

    package main

    import (
    "testing"
    )

    func use(s []byte) {}

    func BenchmarkIndex(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := 0; i <= len(s); i++ {
    use(s[i:])
    }
    }
    }

    func BenchmarkSlice(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := s; len(i) > 0; i = i[1:] {
    use(i)
    }
    }
    }

    func BenchmarkRange(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := range s {
    use(s[i:])
    }
    }
    }

    $ go version
    go version devel +c1c2750f9aba Sun Mar 03 06:50:17 2013 +0800 linux/amd64
    $ go test -bench=.
    testing: warning: no tests to run
    PASS
    BenchmarkIndex 50000000 70.3 ns/op
    BenchmarkSlice 50000000 67.5 ns/op
    BenchmarkRange 50000000 67.9 ns/op
    ok bench 10.501s
    $

    Peter
    On Saturday, March 2, 2013 3:25:12 PM UTC-5, Rémy Oudompheng wrote:
    On 2013/3/2 <itmi...@gmail.com <javascript:>> wrote:
    An index i is cheaper, versus a slice copy i, and I'd say that for big
    slices, it would actually matter.
    http://play.golang.org/p/hMIqagp7Gv

    Mitică
    I see similar performance here (even in favour of the reslicing
    trick): (inlining is disabled in benchmarks)

    go1
    BenchmarkIndex 10000000 162 ns/op
    BenchmarkSlice 10000000 156 ns/op

    go1.1
    BenchmarkIndex 10000000 137 ns/op
    BenchmarkSlice 20000000 132 ns/op

    package main

    import (
    "testing"
    )

    func use(s []byte) {}

    func BenchmarkIndex(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := 0; i <= len(s); i++ {
    use(s[i:])
    }
    }
    }

    func BenchmarkSlice(b *testing.B) {
    s := []byte("test hello world and gophers")
    for it := 0; it < b.N; it++ {
    for i := s; len(i) > 0; i = i[1:] {
    use(i)
    }
    }
    }
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Starfish at Mar 3, 2013 at 9:14 am
    I used a range clause before, but in my real code i have multiple slices traversed in the same loop.

    Thanks for the answer!

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Mar 2, 2013 at 9:29 pm

    On Saturday, March 2, 2013 10:13:55 PM UTC+2, itmi...@gmail.com wrote:
    An index i is cheaper, versus a slice copy i

    This part is always true.

    Dan and Rémy - and the spec, for that matter - suggest this it's pointer
    assignment i := c.
    But there's no guarantee in the spec about the underlying arrays. At least
    none that I know of.

    Mitică

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Mar 2, 2013 at 10:03 pm
    It is difficult to conceive of a situation where the following is true and there is no pointer involvement:

    "A slice, once initialized, is always associated with an underlying array that holds its elements. A slice therefore shares storage with its array and with other slices of the same array; by contrast, distinct arrays always represent distinct storage."

    Though I'm always prepared to have my mental model of the world expanded.

    On 03/03/2013, at 7:59 AM, "itmitica@gmail.com " wrote:

    On Saturday, March 2, 2013 10:13:55 PM UTC+2, itmi...@gmail.com wrote:
    An index i is cheaper, versus a slice copy i

    This part is always true.

    Dan and Rémy - and the spec, for that matter - suggest this it's pointer assignment i := c.
    But there's no guarantee in the spec about the underlying arrays. At least none that I know of.

    Mitică

    --
    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+unsubscribe@googlegroups.com .
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Itmitica at Mar 3, 2013 at 11:21 am

    On Sunday, March 3, 2013 12:03:08 AM UTC+2, kortschak wrote:
    It is difficult to conceive of a situation where the following is true
    and there is no pointer involvement
    In the case of mutating slice i, the subject is the memory use, i.e. the
    underlying array automatic handling, the automatic GC mechanisms, along
    with the complete lack of control over those.

    Hence, black boxes ready to issue bugs.
    I'm not saying it necessarily is the case, I'm just saying it may be the
    case.
    Which is reason enough.

    Mitică

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Mar 3, 2013 at 11:30 am

    On 2013/3/2 Dan Kortschak wrote:
    It is difficult to conceive of a situation where the following is true and
    there is no pointer involvement:

    "A slice, once initialized, is always associated with an underlying array
    that holds its elements. A slice therefore shares storage with its array and
    with other slices of the same array; by contrast, distinct arrays always
    represent distinct storage."

    Though I'm always prepared to have my mental model of the world expanded.
    The Go specification does not specify a complexity for slice
    assignment (maybe it should).

    In a hypothetical Go implementation where goroutines would be
    ditributed across multiple computers, you could imagine that assigning
    a slice may copy the whole underlying data locally for work by a
    goroutine to avoid network costs, then synchronize back the data at a
    synchronization point (to satisfy the memory model) so that other
    goroutines can observe changes to the data (which is "shared").

    Rémy.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Mar 3, 2013 at 7:59 pm
    Yeah, fair enough. Thanks for providing that example.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 2, '13 at 7:57p
activeMar 3, '13 at 7:59p
posts11
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase