Grokbase › Groups › Go › golang-nuts › October 2014
FAQ
From what I understand, append is pretty quick, but obviously resizing has
a cost, so it ought to be at least somewhat faster to make a slice as long
as I intend to use and then just fill in its contents directly by index.
That's what I default to if I know the length. But presently I have a
situation where I know the maximum length, say 100 items, but expect only
to use a fraction of that, say 30 items. So here's the questions.
Theoretically, what would be better, create an array with a capacity of
100, fill in what is needed, and slice off the rest, or create an empty
list and use append? Or in other terms, is the speed gained from not
having to grow the list worth the extra garbage created by specifying a
larger capacity than will actually be used? Hope that makes sense.

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Egon at Oct 27, 2014 at 2:38 pm ⇧

    On Monday, 27 October 2014 16:15:03 UTC+2, Meester Guy Person wrote:
    From what I understand, append is pretty quick, but obviously resizing has
    a cost, so it ought to be at least somewhat faster to make a slice as long
    as I intend to use and then just fill in its contents directly by index.
    That's what I default to if I know the length. But presently I have a
    situation where I know the maximum length, say 100 items, but expect only
    to use a fraction of that, say 30 items. So here's the questions.
    Theoretically, what would be better, create an array with a capacity of
    100, fill in what is needed, and slice off the rest, or create an empty
    list and use append?
    It depends on the actual problem/context.

    Or in other terms, is the speed gained from not having to grow the list
    worth the extra garbage created by specifying a larger capacity than will
    actually be used? Hope that makes sense.
    Simply specify the capacity of the slice, e.g.

    items := make([]Item, 0, 30)
    items = append(items, Item{})

    How to pick the capacity:
    1. get the distribution of items in that array
    2. use the 90th percentile (or some other appropriate number)

    Basically, optimize for the common cases, and let the runtime handle the
    rest. *Of course, only when optimization is actually necessary.*

    + egon

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Adam at Oct 27, 2014 at 6:16 pm ⇧
    I'd use an internal scratch slice of max size, do work the work in scratch
    and copy to a new slice with length of scratch, and return that. This would
    avoid the possibility of append resizing the underlying array multiple
    times. If you aren't worried about the wasted space in the underlying array
    then the scratch slice could be returned, ignoring the copy to an
    appropriately sized slice.
    On Monday, October 27, 2014 10:15:03 AM UTC-4, Meester Guy Person wrote:

    From what I understand, append is pretty quick, but obviously resizing has
    a cost, so it ought to be at least somewhat faster to make a slice as long
    as I intend to use and then just fill in its contents directly by index.
    That's what I default to if I know the length. But presently I have a
    situation where I know the maximum length, say 100 items, but expect only
    to use a fraction of that, say 30 items. So here's the questions.
    Theoretically, what would be better, create an array with a capacity of
    100, fill in what is needed, and slice off the rest, or create an empty
    list and use append? Or in other terms, is the speed gained from not
    having to grow the list worth the extra garbage created by specifying a
    larger capacity than will actually be used? Hope that makes sense.
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Akwillis at Oct 27, 2014 at 6:17 pm ⇧
    I'd use an internal scratch slice of max size, do work the work in scratch
    and copy to a new slice with length of scratch, and return that. This would
    avoid the possibility of append resizing the underlying array multiple
    times. If you aren't worried about the wasted space in the underlying array
    then the scratch slice could be returned, ignoring the copy to an
    appropriately sized slice.
    On Monday, October 27, 2014 10:15:03 AM UTC-4, Meester Guy Person wrote:

    From what I understand, append is pretty quick, but obviously resizing has
    a cost, so it ought to be at least somewhat faster to make a slice as long
    as I intend to use and then just fill in its contents directly by index.
    That's what I default to if I know the length. But presently I have a
    situation where I know the maximum length, say 100 items, but expect only
    to use a fraction of that, say 30 items. So here's the questions.
    Theoretically, what would be better, create an array with a capacity of
    100, fill in what is needed, and slice off the rest, or create an empty
    list and use append? Or in other terms, is the speed gained from not
    having to grow the list worth the extra garbage created by specifying a
    larger capacity than will actually be used? Hope that makes sense.
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Akwillis at Oct 27, 2014 at 6:20 pm ⇧
    I'd use an internal scratch slice of max size, do the work in scratch and
    copy to a new slice with length of scratch, and return that. This would
    avoid the possibility of append resizing the underlying array multiple
    times. If you aren't worried about the wasted space in the underlying array
    then the scratch slice could be returned, ignoring the copy to an
    appropriately sized slice.
    On Monday, October 27, 2014 10:15:03 AM UTC-4, Meester Guy Person wrote:

    From what I understand, append is pretty quick, but obviously resizing has
    a cost, so it ought to be at least somewhat faster to make a slice as long
    as I intend to use and then just fill in its contents directly by index.
    That's what I default to if I know the length. But presently I have a
    situation where I know the maximum length, say 100 items, but expect only
    to use a fraction of that, say 30 items. So here's the questions.
    Theoretically, what would be better, create an array with a capacity of
    100, fill in what is needed, and slice off the rest, or create an empty
    list and use append? Or in other terms, is the speed gained from not
    having to grow the list worth the extra garbage created by specifying a
    larger capacity than will actually be used? Hope that makes sense.
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Akwillis at Oct 27, 2014 at 9:15 pm ⇧
    two examples to help explain my thoughts.

    http://play.golang.org/p/90HDRYGNhe
    http://play.golang.org/p/BzPkYs6EZu
    On Monday, October 27, 2014 2:20:32 PM UTC-4, akwillis wrote:

    I'd use an internal scratch slice of max size, do the work in scratch and
    copy to a new slice with length of scratch, and return that. This would
    avoid the possibility of append resizing the underlying array multiple
    times. If you aren't worried about the wasted space in the underlying array
    then the scratch slice could be returned, ignoring the copy to an
    appropriately sized slice.
    On Monday, October 27, 2014 10:15:03 AM UTC-4, Meester Guy Person wrote:

    From what I understand, append is pretty quick, but obviously resizing
    has a cost, so it ought to be at least somewhat faster to make a slice as
    long as I intend to use and then just fill in its contents directly by
    index. That's what I default to if I know the length. But presently I
    have a situation where I know the maximum length, say 100 items, but expect
    only to use a fraction of that, say 30 items. So here's the questions.
    Theoretically, what would be better, create an array with a capacity of
    100, fill in what is needed, and slice off the rest, or create an empty
    list and use append? Or in other terms, is the speed gained from not
    having to grow the list worth the extra garbage created by specifying a
    larger capacity than will actually be used? Hope that makes sense.
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 27, '14 at 2:15p
activeOct 27, '14 at 9:15p
posts6
users4
websitegolang.org

4 users in discussion

Akwillis: 3 posts Meester Guy Person: 1 post Adam: 1 post Egon: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase