a little app, a few random questions
exh
I got curious about go a few weeks ago and decided to dive in and try
out a project. The result is a simple little graphics app you can see
here
http://obscure-texts.blogspot.com/2010/03/what-is-this-arclight-is-tool-for.html
I came away extremely impressed. Go walks an elegant line between
simplicity and power, and I already enjoy it more than languages I've
worked in for years. Naturally I have a few loose ends I couldn't
suss out for myself.
1. I'm not clear on any performance differences between
func (o *Type)
and
func (o Type)
Does the 2nd always make a copy of Type that ends up getting tossed?
What overhead does this entail?
2. Between an array and a slice, is there a performance penalty for
accessing an element in the slice?
3. Is there a way to pass function literals as arguments to other
functions? In my head I naively see syntax that looks something like
func receiver(func inner()) {
// setup
inner()
// tear down
}
func sender() {
// do stuff
receiver(func() {
// do more stuff
}())
// do final stuff
...if that makes any sense at all.
That's it offhand. Thanks for any info!
eric
Andrew Gerrand
> I got curious about go a few weeks ago and decided to dive in and try
> out a project. The result is a simple little graphics app you can see
> here
> http://obscure-texts.blogspot.com/2010/03/what-is-this-arclight-is-tool-for.html
A very neat tool!
> 1. I'm not clear on any performance differences between
>
> func (o *Type)
> and
> func (o Type)
>
> Does the 2nd always make a copy of Type that ends up getting tossed?
> What overhead does this entail?
It depends on the size of your struct. The bigger the struct, the
larger the memory copy required. The compiler guys would be able to
answer your question in more detail, but I would say in most cases
it's a negligible overhead.
> 2. Between an array and a slice, is there a performance penalty for
> accessing an element in the slice?
Again, I think any performance penalty would be negligible. I'd
suggest benchmarking against your particular application.
> 3. Is there a way to pass function literals as arguments to other
> functions? In my head I naively see syntax that looks something like
You most certainly can! It's one of the great features of Go.
Modifying your example to make it actually do something:
package main
import "fmt"
func receiver(inner func() string) {
fmt.Println("Hi " + inner())
}
func sender() {
receiver(func() string { return "exh" })
}
func main() { sender() }
> func receiver(func inner()) {
> // setup
> inner()
> // tear down
> }
>
> func sender() {
> // do stuff
> receiver(func() {
> // do more stuff
> }())
> // do final stuff
>
> ...if that makes any sense at all.
>
> That's it offhand. Thanks for any info!
> eric
>
Hope this helps.
Andrew
Eric Hackborn EH
>> accessing an element in the slice?
>
> Again, I think any performance penalty would be negligible. I'd
> suggest benchmarking against your particular application.
It's not remotely applicable at the moment, but I was thinking in
terms of audio processing. I believe the spec says that in traditional
arrays, the size is part of the type, and can only be set at compile
time, which makes them fairly unsuitable for storing buffers of audio
data (since the size would vary so drastically between users, and the
worst case would make them very large). So that leaves slices, but
any overhead at all on accessing elements, when you're doing that for
hundreds of streams running at 48 or 96 kHz, can be disastrous. Maybe
I'm missing something basic, or maybe Go just isn't intended for
content creation apps.
>> 3. Is there a way to pass function literals as arguments to other
>> functions? In my head I naively see syntax that looks something like
>
> You most certainly can! It's one of the great features of Go.
Sweet, thanks much, that's exactly what I wanted!
thanks,
eric
Russ Cox
> terms of audio processing. I believe the spec says that in traditional
> arrays, the size is part of the type, and can only be set at compile
> time, which makes them fairly unsuitable for storing buffers of audio
> data (since the size would vary so drastically between users, and the
> worst case would make them very large). So that leaves slices, but
> any overhead at all on accessing elements, when you're doing that for
> hundreds of streams running at 48 or 96 kHz, can be disastrous. Maybe
> I'm missing something basic, or maybe Go just isn't intended for
> content creation apps.
The only slice access overhead is the index bounds check,
and that applies to arrays too. Otherwise they behave just
like arrays in C. It seems like that should be plenty fast.
Russ
David Jones
array?
If I understood correctly, slices can only get as big as the
underlying array. How would that solve the problem? Shouldn't he
rather use a list or something?
Or is there a way to dynamically resize slices to any size necessary?
thanks, David
--
Subscription settings: http://groups.google.com/group/golang-nuts/subscribe?hl=en
befelemepeseveze
> Sorry to dig up the old thread, but aren't slices built around an
> array?
> If I understood correctly, slices can only get as big as the
> underlying array. How would that solve the problem? Shouldn't he
> rather use a list or something?
> Or is there a way to dynamically resize slices to any size necessary?
and content copying.
http://golang.org/doc/effective_go.html#slices
<quoted>
Here is a function to append data to a slice. If the data exceeds the
capacity, the slice is reallocated. The resulting slice is returned.
The function uses the fact that len and cap are legal when applied to
the nil slice, and return 0.
func Append(slice, data[]byte) []byte {
l := len(slice)
if l + len(data) > cap(slice) { // reallocate
// Allocate double what's needed, for future growth.
newSlice := make([]byte, (l+len(data))*2)
// The copy function is predeclared and works for any slice
type.
copy(newSlice, slice)
slice = newSlice
}
slice = slice[0:l+len(data)]
for i, c := range data {
slice[l+i] = c
}
return slice
}
</quoted>
Rob 'Commander' Pike
$ godoc -src bytes Add
// Add appends the contents of t to the end of s and returns the result.
// If s has enough capacity, it is extended in place; otherwise a
// new array is allocated and returned.
func Add(s, t []byte) []byte {
lens := len(s)
lent := len(t)
if lens+lent <= cap(s) {
s = s[0 : lens+lent]
} else {
news := make([]byte, lens+lent, resize(lens+lent))
copy(news, s)
s = news
}
copy(s[lens:lens+lent], t)
return s
}
$
David Jones
On 26 Apr., 16:51, "Rob 'Commander' Pike" <r...@google.com> wrote:
> Here's a shorter example from the distribution.
>
> $ godoc -src bytes Add
> // Add appends the contents of t to the end of s and returns the result.
> // If s has enough capacity, it is extended in place; otherwise a
> // new array is allocated and returned.
> func Add(s, t []byte) []byte {
> lens := len(s)
> lent := len(t)
> if lens+lent <= cap(s) {
> s = s[0 : lens+lent]
> } else {
> news := make([]byte, lens+lent, resize(lens+lent))
> copy(news, s)
> s = news
> }
> copy(s[lens:lens+lent], t)
> return s}
>