[go-nuts] Ranging over slices vs using for with an index

On Thursday, 10 April 2014 15:59:49 UTC+10, William Kennedy wrote:

I have read the spec on the use of the keyword range:
http://golang.org/ref/spec#RangeClause

Using this code as a reference for my questions:

func Range() {

for _, value := range data {

Foo(value)

}

}


func Index() {

for index := 0; index < len(data); index++ {

Foo(data[index])

}

}


Shouldn't using an index to access each value from a slice be more
efficient than using a for-range and creating a copy. Especially if value
is based on a user-defined type with a few fields?

What is the advantage of using for-range over using a for with an index?

Is the answer that the for-range is simpler, and less error prone. Plus it
eliminates the bounds checking that Go is executing with each call to
data[index]?

I have read the spec on the use of the keyword range:
http://golang.org/ref/spec#RangeClause

Using this code as a reference for my questions:

func Range() {

for _, value := range data {

Foo(value)

}

}


func Index() {

for index := 0; index < len(data); index++ {

Foo(data[index])

}

}


Shouldn't using an index to access each value from a slice be more efficient
than using a for-range and creating a copy. Especially if value is based on
a user-defined type with a few fields?

What is the advantage of using for-range over using a for with an index?

Is the answer that the for-range is simpler, and less error prone. Plus it
eliminates the bounds checking that Go is executing with each call to
data[index]?

--
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/d/optout.

On Apr 10, 2014, at 2:33 AM, Caleb Spare wrote:

It's impossible to make blanket statements about optimizations like
this. It depends on many factors, including:

- The types of slices you're using
- Hardware peculiarities
- Optimizations in the Go compiler you're using (which change as it matures)

This case is absolutely not worth "optimizing" in the general case;
only if it's provably a bottleneck in a very tight loop should you
even spend any time thinking about it.

In that case, testing.B is your friend.

Here is a simple benchmark in which the range version is faster than
the index version, BUT only for

- my computer and Go compiler
- a particular workload (a running sum)
- a particular slice type ([]int)

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

I make no claims about the general relative performance of for/range
vs traditional for.

-Caleb

On Wed, Apr 9, 2014 at 10:59 PM, William Kennedy
wrote:

On Apr 10, 2014, at 8:24 AM, William Kennedy wrote:


So maybe my question was too generic, but I was curious if there was more to this than meets the eye. If I don't ask, I can't learn.

I was not attempting for anyone to make a blanket statement. I also created benchmarks where range performed better. Your example is much better, thanks.

I was hoping for answers like Dave's. I have been thinking lately about how mechanical sympathy for the Go runtime, OS and hardware should play a role in the code we write.

I have clients who are selling products with features I haven't even coded yet. My timeframes are ridiculous and I always need to get something out quickly that is solid and performs. I don't always have time to benchmark everything or make fine-tuned decisions. I think this is the reality for a lot of people. Go has made this situation much better for me.

The more I learn, I realize that if I write idiomatic Go and follow good form, I get a lot of mechanical sympathy out of the box. I am learning that the go dev team has already incorporated mechanical sympathy into the language and runtime. Go does not put performance ahead of other things, such as fast compile times and safer code, yet the performance is there. I can trust these things and when I have time, benchmark and refactor later.

I was just looking for guidance on what was good form in this particular generic example. I think you both answered the question for me. Thanks.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/V_03s9ClyJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Fri, Apr 11, 2014 at 6:12 PM, Andy Balholm wrote:

If you're worried about the value being copied, you can use the
single-valued form of range (for i := range data). That should have all the
advantages (if any) of the for i := 0 version, and still be able to avoid
bounds checks.

--
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/d/optout.

On Apr 11, 2014, at 2:46 PM, Henrik Johansson wrote:

Really? The range notation with indexing avoids bounds checks?

On Fri, Apr 11, 2014 at 8:58 PM, William Kennedy wrote:
I think Andy was trying to say that you can use the range to get an index
and not worry about when to end the for loop. Range takes care of that
internally for you. Obviously you need to use the index to select a
specific element from the slice. That operation would require a bounds
check.

On Apr 11, 2014, at 11:46 AM, Henrik Johansson wrote:

Really? The range notation with indexing avoids bounds checks?

On 12/04/2014, at 3:00 PM, "Andy Balholm" wrote:

I was wrong. It generates exactly the same code as for i := 1; i < len(s); i++.

On Apr 12, 2014, at 12:44 AM, Dan Kortschak wrote:

More realistically i, l := 0, len(s); i < l; i++

On 13/04/2014, at 1:01 AM, "Andy Balholm" wrote:

Well, starting with 0 anyway! :-( I should have copied directly from my working code.

But if you replace that 1 with a 0, the assembly output is actually identical to for i := range s