FAQ
Hi,

I see the phrase "don't create a lot of garbage" used a lot, and I was
hoping for a clarification. Does "a lot" refer to the number of objects,
the amount of memory used, or some combination of both? Does this also
apply to really small variables like ints and bools? I know the most
accurate answer is "profile and find out", but I am hoping for some rules
of thumb.

Thanks

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

  • Rob Pike at Apr 5, 2013 at 5:26 pm
    Memory management is expensive no matter how it is implemented, so when
    performance matters it's always better to avoid allocation when it's not
    necessary. Allocate what's needed and no more; reuse when it's practical;
    measure when you're unsure.

    Small things like ints and bools probably live on the stack or inside other
    data structures are not explicitly allocated, so they usually don't fall
    under these guidelines.

    -rob

    --
    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.
  • Brendan Tracey at Apr 5, 2013 at 7:42 pm
    Okay, I understand. Thanks.

    On Apr 5, 2013, at 10:26 AM, Rob Pike wrote:

    Memory management is expensive no matter how it is implemented, so when performance matters it's always better to avoid allocation when it's not necessary. Allocate what's needed and no more; reuse when it's practical; measure when you're unsure.

    Small things like ints and bools probably live on the stack or inside other data structures are not explicitly allocated, so they usually don't fall under these guidelines.

    -rob
    --
    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.
  • Hamish Ogilvy at Apr 6, 2013 at 5:21 pm
    As Rob says if you don't need to, don't allocate. If you run an application that is heavily running the same function over and over its amazing how reducing the variable allocation in that function will reduce garbage. Things that aren't a problem under normal use can blow out memory really quick.

    You should really think about every variable allocation carefully as I've also seen plenty of functions speed up enormously when a map or slice is created with a realistic number of elements rather than few or none, as the copy (to expand repeatedly) gets very costly compared to just allocating that space from the outset.

    I take a good look at every := when first seeing memory creep.

    --
    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.
  • Kevin Gillette at Apr 6, 2013 at 5:40 pm
    As I understand it, in gc and gccgo's allocator/collector implementations,
    the number of allocated objects (and pointers) affect collection/sweep
    speed much more than the amount of memory allocated affects it.
    On Friday, April 5, 2013 11:23:06 AM UTC-6, Brendan Tracey wrote:

    Hi,

    I see the phrase "don't create a lot of garbage" used a lot, and I was
    hoping for a clarification. Does "a lot" refer to the number of objects,
    the amount of memory used, or some combination of both? Does this also
    apply to really small variables like ints and bools? I know the most
    accurate answer is "profile and find out", but I am hoping for some rules
    of thumb.

    Thanks
    --
    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.
  • Brendan Tracey at Apr 7, 2013 at 10:07 pm
    Does reslicing a slice count as creating a lot of garbage? For example,
    let's say I'm running a piece of code a bunch of times, and the naive
    approach would be to have a couple of make([]float64, len) at the top. Is
    a good solution to pass in a large slice of floats and index sub-indices,
    or does that defeat the purpose? In my case, for example, it would allow me
    to do

    tmp memory := make([]float64, largeLength)
    for i :=0; i<1000; i++{



    On Saturday, April 6, 2013 10:40:18 AM UTC-7, Kevin Gillette wrote:

    As I understand it, in gc and gccgo's allocator/collector implementations,
    the number of allocated objects (and pointers) affect collection/sweep
    speed much more than the amount of memory allocated affects it.
    On Friday, April 5, 2013 11:23:06 AM UTC-6, Brendan Tracey wrote:

    Hi,

    I see the phrase "don't create a lot of garbage" used a lot, and I was
    hoping for a clarification. Does "a lot" refer to the number of objects,
    the amount of memory used, or some combination of both? Does this also
    apply to really small variables like ints and bools? I know the most
    accurate answer is "profile and find out", but I am hoping for some rules
    of thumb.

    Thanks
    --
    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.
  • Brendan Tracey at Apr 7, 2013 at 10:17 pm
    Does reslicing a slice count as creating a lot of garbage? For example,
    let's say I'm running a piece of code a bunch of times, and the naive
    approach would be to have a couple of make([]float64, len) at the top. Is
    a good solution to pass in a large slice of floats and index sub-indices,
    or does that defeat the purpose?

    For example, code a:
    for i :=0; i<1000; i++{
    a := make([]float64,10)
    tmp := make([]float64, 30)
    Foo1(a, tmp)
    b := make([]float64, 20)
    tmp = make([]float64, 30)
    Foo2(b, tmp)
    Foo3(a,b)
    }





    tmpMemory := make([]float64, 60)
    for i :=0; i<1000; i++{
    a := tmpMemory([:10])
    Foo1(a, tmpMemory[10:40])
    b := tmpMemory([10:30])
    Foo2(b, tmpMemory[30:60])
    Foo3(a,b)
    }

    I suppose it would be faster to set a and b outside the for loop (and I'll
    have to think if it can be done outside the loop in my actual case), but
    barring that, has the second code accomplished anything? I think that's
    similar to asking if reslicing is okay but allocating new memory is not?

    Thanks

    On Saturday, April 6, 2013 10:40:18 AM UTC-7, Kevin Gillette wrote:

    As I understand it, in gc and gccgo's allocator/collector implementations,
    the number of allocated objects (and pointers) affect collection/sweep
    speed much more than the amount of memory allocated affects it.
    On Friday, April 5, 2013 11:23:06 AM UTC-6, Brendan Tracey wrote:

    Hi,

    I see the phrase "don't create a lot of garbage" used a lot, and I was
    hoping for a clarification. Does "a lot" refer to the number of objects,
    the amount of memory used, or some combination of both? Does this also
    apply to really small variables like ints and bools? I know the most
    accurate answer is "profile and find out", but I am hoping for some rules
    of thumb.

    Thanks
    --
    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 Apr 7, 2013 at 10:32 pm

    On 2013/4/8 Brendan Tracey wrote:
    Does reslicing a slice count as creating a lot of garbage? For example,
    let's say I'm running a piece of code a bunch of times, and the naive
    approach would be to have a couple of make([]float64, len) at the top. Is a
    good solution to pass in a large slice of floats and index sub-indices, or
    does that defeat the purpose?
    Slicing can be thought (in my opinion) as Go's equivalent of pointer
    arithmetic, or rather, slice arithmetic; it does not imply a memory
    allocation.

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 5, '13 at 5:23p
activeApr 7, '13 at 10:32p
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase