FAQ

On 2012/06/27 13:42:09, rsc wrote:
I already said that I would like to have a discussion about memory
reduction strategies when I am back in a few weeks. I do not plan to
look at this CL before having that discussion.
Hello,

Would it be possible to separate the changes to the 1bit fields into an
independent CL?

Cheers

Dave

https://codereview.appspot.com/6345044/

Search Discussions

  • 0xe2 0x9a 0x9b at Oct 12, 2012 at 9:16 pm

    On 2012/10/11 00:33:30, dfc wrote:
    On 2012/06/27 13:42:09, rsc wrote:
    I already said that I would like to have a discussion about memory
    reduction strategies when I am back in a few weeks. I do not plan to
    look at this CL before having that discussion.
    Hello,
    Would it be possible to separate the changes to the 1bit fields into an
    independent CL?
    http://codereview.appspot.com/6650054

    https://codereview.appspot.com/6345044/
  • Dave Cheney at Oct 13, 2012 at 12:32 am
    Thank you.
    On Sat, Oct 13, 2012 at 4:00 AM, wrote:
    On 2012/10/11 00:33:30, dfc wrote:
    On 2012/06/27 13:42:09, rsc wrote:
    I already said that I would like to have a discussion about memory
    reduction strategies when I am back in a few weeks. I do not plan to
    look at this CL before having that discussion.
    Hello,
    Would it be possible to separate the changes to the 1bit fields into an
    independent CL?

    http://codereview.appspot.com/6650054

    https://codereview.appspot.com/6345044/
  • 0xe2 0x9a 0x9b at Oct 15, 2012 at 2:24 pm
    Hello dave@cheney.net, rsc@golang.org, bradfitz@golang.org,
    lvd@google.com (cc: golang-dev@googlegroups.com),

    Please take another look.


    http://codereview.appspot.com/6345044/
  • Russ Cox at Nov 1, 2012 at 6:44 pm
    I am still interested in this CL, but I would like to see a memory
    profile showing what memory usage looks like before we start fixing
    things. One way to get a memory profile would be to hook it up on
    Linux to the C++ pprof (http://code.google.com/p/gperftools).
  • 0xe2 0x9a 0x9b at Nov 3, 2012 at 9:25 am
    Hello dave@cheney.net, rsc@golang.org, bradfitz@golang.org,
    lvd@google.com (cc: golang-dev@googlegroups.com),

    Please take another look.


    http://codereview.appspot.com/6345044/
  • 0xe2 0x9a 0x9b at Nov 3, 2012 at 9:44 am

    On 2012/11/01 18:44:19, rsc wrote:
    I am still interested in this CL, but I would like to see a memory
    profile showing what memory usage looks like before we start fixing
    things. One way to get a memory profile would be to hook it up on
    Linux to the C++ pprof (http://code.google.com/p/gperftools).
    I used Valgrind. When compiling godoc with 8g, the call counts are:

    nod(): 357782 calls, 357782 calls to mal()
    funcnode(): 21654 calls, 17648 mal()
    unode(): 4470 calls, 3690 mal()

    Sizes in bytes (8g):

    sizeof(Node) = 180 (old size: 216)
    sizeof(FuncNode) = 40
    sizeof(UncommonNode) = 20

    The theoretical difference in memory usage when compiling godoc is
    approximately 340000*(216-180) = 12MiB. Actual difference as measured by
    /usr/bin/time is 10MiB (=131-121).

    ---

    Note: A new struct UncommonNode and function unode() has been added to
    the changeset. Maybe we could move additional uncommon fields from Node
    to UncommonNode before the decision to merge this changeset into Go is
    made.

    https://codereview.appspot.com/6345044/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 11, '12 at 12:39a
activeNov 3, '12 at 9:44a
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase