Constant References in Go?

[tux21b]

Hi everyone!

I've just finished my first Go project (a minimalistic raytracer).
During the development
people in #go-nuts told me that passing pointers to non-primitive
datatypes to functions and methods is faster than passing the non-
primitive datatype by value. That fact where once very crucial [1] in
one of my past C++ projects (a more complex raytracer).

During that bigger C++ project, I got used to use const references for
all input parameters where ever possible (for all non primitive
types). So I tried to do something like that in my Go project too, so
I've started using pointers there. The result was:

* Every method/function now contains a lot of not-nil pointer checks
at the beginning
* I've to be extremely careful not to change any parameter by
accident
* I've to write a "&" in front of nearly all parameters when I call
any function/method
* The runtime must dereference my pointer (I don't really care about
that)

So, the point is, it would be nice to have something in Go too. Either
some kind of const references or just a by-reference hint or something
like that.

At the moment, I haven't benchmarked any Go project, but I am still
interested about this topic. Maybe someone with a deeper Go knowledge
can share some thoughts on that.

[1]: Unfortunately I don't remember the exact performance improvement,
but I think it was about 1/3.

Regards,
Christoph

[ptolomy23]

On Thu, Sep 16, 2010 at 2:53 PM, tux21b <c.h...@gmx.at> wrote:

Hi everyone!

I've just finished my first Go project (a minimalistic raytracer).
During the development
people in #go-nuts told me that passing pointers to non-primitive
datatypes to functions and methods is faster than passing the non-
primitive datatype by value. That fact where once very crucial [1] in

If someone told you that, they didn't tell you the whole story.

First, I should note that carefully performance tuning code for 6g/8g may be silly at this point. They don't do as many optimizations as a lot of other compilers, so you can get measurable speedups by inlining functions or restructuring loops/conditionals in somewhat arbitrary ways. This may change (I heard rumors of inlining being on its way), and once gccgo is working you'll probably be able to get better  performance without odd tweaks. So, unless you are just doing it for the sheer fun of optimization, you're better off writing your code the way that makes the most sense.

Anyhow, passing pointers vs passing values. One problem is that in many cases taking the address of something results in it being allocated on the heap. As it turns out, memory management in Go isn't too fast yet, so this can be a major slowdown. However, if you're passing the same thing around a lot, this is amortized. The advantage of passing pointers is that you potentially have less copying to do, but copying can be pretty darn fast, and with values it can be easier to safely parallelize. I think the relative performance depends very much on your specific case. Avoid allocation where you can, but use what construct makes sense, and tweak things if your benchmarks or generated code

give you a good cause to. 

[peterGo]

tux21b,

It's unlikely that const will be added to the type system.
http://groups.google.com/group/golang-nuts/msg/7d7ec2854db125f2

Peter