FAQ
Apologies if this is a dumb question. i come from the land of the hidden
pointers.

if you implement a mathematical library that uses pointers in its function
params, how does this affect performance? Is there a cost to the
indirection?

Also, presumably not using pointers results in a new copy being added to
heap that needs to be GCd later. Is that the only difference from a memory
standpoint?

Finally, if there is a reference to performance, memory and GC that covers
all this, a pointer (no pun intended) would be appreciated.

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

Search Discussions

  • Jan Mercl at Nov 19, 2015 at 1:19 pm

    On Thu, Nov 19, 2015 at 2:01 PM Larry wrote:
    if you implement a mathematical library that uses pointers in its
    function params, how does this affect performance? Is there a cost to the
    indirection?

    Yes, there's always a cost of indirection (accessing a value through
    dereferencing a pointer). There's also always a cost of copying a
    non-indirected value. Which of the costs is greater depends on many things,
    including a particular CPU architecture/model/cache sizes. Other than that,
    a rough estimate is that copying a "small" value, for some value of small,
    might have also a rather small cost, ie. using a pointer instead might not
    be necessary. OTOH, passing "big" values by value (copying them) is
    probably always something one should try to avoid.
    Also, presumably not using pointers results in a new copy being added to
    heap that needs to be GCd later. Is that the only difference from a memory
    standpoint?

    Copying a value up to certain (quite big) size is performed on the stack so
    it does not create any GC pressure.
    Finally, if there is a reference to performance, memory and GC that
    covers all this, a pointer (no pun intended) would be appreciated.

    I think the best, perhaps the only good option, is to benchmark (go test
    -bench <re>) the numbers for yourself and for the particular machine and
    program (add -benchmem to get also mem stats).

    --

    -j

    --
    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.
  • Japanified at Nov 19, 2015 at 4:52 pm

    Apologies if this is a dumb question. i come from the land of the hidden
    pointers.

    if you implement a mathematical library that uses pointers in its function
    params, how does this affect performance? Is there a cost to the
    indirection?

    Also, presumably not using pointers results in a new copy being added to
    heap that needs to be GCd later. Is that the only difference from a memory
    standpoint?

    Finally, if there is a reference to performance, memory and GC that covers
    all this, a pointer (no pun intended) would be appreciated.

    thanks.
    https://groups.google.com/forum/#!topic/golang-nuts/H7LrVJhXyv4

    Passed parameters will end up on the stack which is not garbage collected
    in the sense that I believe you are referring to.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 19, '15 at 1:00p
activeNov 19, '15 at 4:52p
posts3
users3
websitegolang.org

3 users in discussion

Jan Mercl: 1 post Larry: 1 post Japanified: 1 post

People

Translate

site design / logo © 2021 Grokbase