FAQ

Search Discussions

  • 0xe2 0x9a 0x9b at Oct 12, 2012 at 6:13 pm
    Hello golang-dev@googlegroups.com, minux.ma@gmail.com (cc:
    golang-dev@googlegroups.com),

    Please take another look.


    http://codereview.appspot.com/6650054/
  • Rsc at Oct 12, 2012 at 7:38 pm
    I'm sorry, but we're not going to use bitfields here. They have a long
    history of problems and complications, and I'd prefer that we keep them
    out of this code base.

    I have no problem collapsing the fields into a uint64 flag or something
    like that, which can be tested with if(n->flag & Whatever) etc.

    I'm a little surprised that these 6 bytes are the main memory overhead.
    Removing even a single pointer field, such as by making Val val into Val
    *val, allocated as needed, seems like it would have a larger effect.

    I think there's interesting work to be done here but I would prefer it
    to be driven by profiling data.

    https://codereview.appspot.com/6650054/
  • 0xe2 0x9a 0x9b at Oct 12, 2012 at 8:27 pm

    On 2012/10/12 18:35:23, rsc wrote:
    I'm sorry, but we're not going to use bitfields here. They have a long history
    of problems and complications, and I'd prefer that we keep them out of this code
    base.
    The bitfields were part of CL 6345044. I will delete them from 6345044.
    I have no problem collapsing the fields into a uint64 flag or
    something like
    that, which can be tested with if(n->flag & Whatever) etc.
    I'm a little surprised that these 6 bytes are the main memory
    overhead.

    It is true that there exist larger memory overheads.
    Removing
    even a single pointer field, such as by making Val val into Val *val, allocated
    as needed, seems like it would have a larger effect.
    sizeof(Val) is just 2 pointers, so the effect of replacing it with Val*
    is of the same order as the effect of collapsing the 6 bytes in this CL.

    The code in src/cmd/gc/walk.c seems incorrect (uchar may overflow?), so
    at the very least we could merge src/cmd/gc/walk.c
    I think there's interesting work to be done here but I would prefer it to be
    driven by profiling data.
    https://codereview.appspot.com/6650054/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 12, '12 at 6:05p
activeOct 12, '12 at 8:27p
posts4
users3
websitegolang.org

3 users in discussion

0xe2 0x9a 0x9b: 2 posts Rsc: 1 post Minux Ma: 1 post

People

Translate

site design / logo © 2022 Grokbase