FAQ
Hello bradfitz@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go


http://codereview.appspot.com/6843056/

Search Discussions

  • Dave at Nov 20, 2012 at 9:18 am
    Hi Jeff,

    Thanks for this proposal. I don't think the performance gain here is
    worth the extra code and extra bookkeeping overhead, so i'm -1 on this
    proposal.

    Cheers

    Dave


    https://codereview.appspot.com/6843056/diff/13001/src/pkg/net/http/request.go
    File src/pkg/net/http/request.go (right):

    https://codereview.appspot.com/6843056/diff/13001/src/pkg/net/http/request.go#newcode453
    src/pkg/net/http/request.go:453: defer tpFree.put(tp)
    The defer costs you an allocation so I don't think this is a net saving.

    https://codereview.appspot.com/6843056/diff/13001/src/pkg/net/http/response.go
    File src/pkg/net/http/response.go (right):

    https://codereview.appspot.com/6843056/diff/13001/src/pkg/net/http/response.go#newcode107
    src/pkg/net/http/response.go:107: defer tpFree.put(tp)
    see previous

    https://codereview.appspot.com/6843056/
  • Brad Fitzpatrick at Nov 20, 2012 at 6:01 pm
    It's easy to write a benchmark that makes a particular optimization look
    good.

    I agree with Dave that this is complicated and weird. Re-using readers
    from http might be a good idea (which could be its own CL, if that
    matters), but why would each reader have its own valueCache? Just to avoid
    some locking? I feel like that should be noise compared to GC costs, if
    this really saves on that.

    On Fri, Nov 16, 2012 at 7:21 AM, wrote:

    Hello bradfitz@golang.org (cc: golang-dev@googlegroups.com),

    I'd like you to review this change to
    https://code.google.com/p/go


    http://codereview.appspot.com/**6843056/<http://codereview.appspot.com/6843056/>
  • Jeff Allen at Nov 21, 2012 at 9:42 am
    I agree that it feels like this change is messy.

    The performance improvement from reducing garbage comes long after the
    function in question is complete. It is hard to measure it, and it is
    only a win in bulk. So as I work on reducing garbage, I make it a goal
    that the function should get faster as well. That way, the wins are
    guaranteed: the function is faster (immediate payoff) AND there's less
    trash (long-term payoff).

    I think I need to build a bit of infrastructure to quantify the GC cost
    reduction so that I can make better decisions about the justifiable
    costs increases.

    Stay tuned. :)

    https://codereview.appspot.com/6843056/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 16, '12 at 3:27p
activeNov 21, '12 at 9:42a
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase