FAQ
Hi all,

I took some time after getting bored being stuck at home sick, to poke the
boundary benchmark a little more. I was disappointed with Go's
representation in the test as well as the numbers displayed overall. In my
experience both platforms should perform better, but in Go's case, there
were "first 5 minutes" indicators of restricting factors. It turns out that
Go's apparent poor performance was due to an innocent hardcoded value in
database/sql. The most minimal patch conceived simply changes the value
from 2 to 8 or 10, and most of the performance that can be attained then
will be. In fact, against tip, I was able to take it much higher than that
(with a tuned postgresql.conf), to hundreds of connections. Be thankful
it's using a pure Go database driver.

Apologies for the slightly inflammatory subject line. It's just for
entertainment.

The real reason for this mail, prior to submitting the patch, is that the
specific approach in the patch could come under some discussion. The
attached diff is probably the "minimal sane" patch that could be applied,
but I have a few items worth discussing. If little discussion comes of it,
I will submit this patch for now, and consider sending additional work if I
can make the time for it. As I am new to this community, I don't yet know
what style of patches are desired. If incremental, sane but incidental
changes such as the attached patch are acceptable, I will start pushing
them through.

Here are my own review thoughts on the patch and surrounding issues:

- The current code defaults to 2 "idle connections". In reality this
equates to 2 "active connections" for various reasons. This default value
is continued only such that users would not be subject to unexpected
semantic changes.
- There is no maximum limit implemented. While not the subject of this
problem or patch, this should be implemented.
- The immediate close behavior (something I am tempted to consider a
bug) has not been altered. This point may become more of a philosophical
discussion. In my experience, it's better to handle bursts with grace where
possible. If this discussion becomes lit, it may be best to split it to
another thread.
- Related to the immediate close behavior, with or without changing that
aspect, I feel that the pool could be rewritten with channels and
goroutines. An almost example lives here
(https://github.com/eventmachine/eventmachine/blob/master/lib/em/pool.rb)
(for those of you with very high attention to detail: yes, that contains
some races that are easier to eradicate in a Go style environment).
- If a channel approach is not taken, it may yet still make sense to at
least move the mutex in database/sql to a RW variant with a persistent
store of Conn objects and a free / use list. This should allow
simplification of the Close anti-race logic. "defer" helps with this stuff,
but, it's not showing itself to be a magic bullet.
- The second comment on Open suggests that drivers will implement an
Open that returns a *DB. This is no longer the case, and this comment
should be removed (if I submit this patch, should I include that or add it
to a second patch - that's the common approach in this community?).
- Given the aforementioned comment on sql.Open, it's not entirely clear
if DB instances should always be created via sql.Open directly. If they
are, then the patch is correct setting maxIdleConns during construction of
the struct in sql.Open, if not, then more work is required to handle the
default in MaxIdleConns() where a value of 0 will be treated as 2, if
bullet 1 is to remain. This latter approach would be unfortunate, because
there are some real world use cases for 0 being a meaningful value.
- It might be useful separately from a maximum value, although related,
to make the implementation act more like a pool (at least optionally).
Right now driver.Conn.Open() is left with the only recourse of panic when a
database server is for example, run out of socket resources. It seems that
Go has all the ability to create this scenario with ease.

On to the Good News:
*
*
The attached patch, as imperfect as it may be, does take the Go
implementation of Collins Go-And-Java test[1] far beyond the Java
implementation. You can find my fork on github[2], and some specific
results in the README.md[3]

16kr/s for Go, and 10kr/s for Java. I'm sure the Java version could be
optimized at least somewhat. Both applications pretty much hose the CPU of
my now quite warm Macbook Pro. The remote side (executing wrk(1)) was a mac
mini with the machines attached between a Gigabit network running MTU 9000.
There are a few more details in the README, but I'm sure I missed relevant
items. The next bottleneck appears to be context switching - I was sharing
the application machine with the Postgresql forks, and the test was
generating more than 50% sys load under tension.

Anyone should be happy with these results (including the Java/Dropwizard
results). They're very good, and clearly demonstrate that for any generally
normal real world application, the infrastructure and libraries in use will
certainly not be the cause of any statistically significant latency.

The last round of tests, on which this numbers are based, came from
"f4a92d7eeb8d" with the attached patch applied.

Thanks,

James

[1]
http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/
[2] https://github.com/raggi/go-and-java
[3] https://github.com/raggi/go-and-java/blob/master/README.md#example-results

--

Search Discussions

  • Job van der Zwan at Sep 30, 2012 at 11:54 pm
    It's obvious that you've put a lot of thought into this. However, this is
    intended more as a "general discussion" section of the Go language (as
    exemplified by the fact that I hardly understand what you're talking about,
    other than the fact that it involves databases and benchmarks). I think
    that you should try the developer group:

    https://groups.google.com/forum/?fromgroups=#!forum/golang-dev

    I'm sure you'll get more feedback there.

    In any case, welcome!
    On Monday, 1 October 2012 00:21:42 UTC+2, (unknown) wrote:

    Hi all,

    I took some time after getting bored being stuck at home sick, to poke the
    boundary benchmark a little more. I was disappointed with Go's
    representation in the test as well as the numbers displayed overall. In my
    experience both platforms should perform better, but in Go's case, there
    were "first 5 minutes" indicators of restricting factors. It turns out that
    Go's apparent poor performance was due to an innocent hardcoded value in
    database/sql. The most minimal patch conceived simply changes the value
    from 2 to 8 or 10, and most of the performance that can be attained then
    will be. In fact, against tip, I was able to take it much higher than that
    (with a tuned postgresql.conf), to hundreds of connections. Be thankful
    it's using a pure Go database driver.

    Apologies for the slightly inflammatory subject line. It's just for
    entertainment.

    The real reason for this mail, prior to submitting the patch, is that the
    specific approach in the patch could come under some discussion. The
    attached diff is probably the "minimal sane" patch that could be applied,
    but I have a few items worth discussing. If little discussion comes of it,
    I will submit this patch for now, and consider sending additional work if I
    can make the time for it. As I am new to this community, I don't yet know
    what style of patches are desired. If incremental, sane but incidental
    changes such as the attached patch are acceptable, I will start pushing
    them through.

    Here are my own review thoughts on the patch and surrounding issues:

    - The current code defaults to 2 "idle connections". In reality this
    equates to 2 "active connections" for various reasons. This default value
    is continued only such that users would not be subject to unexpected
    semantic changes.
    - There is no maximum limit implemented. While not the subject of this
    problem or patch, this should be implemented.
    - The immediate close behavior (something I am tempted to consider a
    bug) has not been altered. This point may become more of a philosophical
    discussion. In my experience, it's better to handle bursts with grace where
    possible. If this discussion becomes lit, it may be best to split it to
    another thread.
    - Related to the immediate close behavior, with or without changing
    that aspect, I feel that the pool could be rewritten with channels and
    goroutines. An almost example lives here (
    https://github.com/eventmachine/eventmachine/blob/master/lib/em/pool.rb)
    (for those of you with very high attention to detail: yes, that contains
    some races that are easier to eradicate in a Go style environment).
    - If a channel approach is not taken, it may yet still make sense to
    at least move the mutex in database/sql to a RW variant with a persistent
    store of Conn objects and a free / use list. This should allow
    simplification of the Close anti-race logic. "defer" helps with this stuff,
    but, it's not showing itself to be a magic bullet.
    - The second comment on Open suggests that drivers will implement an
    Open that returns a *DB. This is no longer the case, and this comment
    should be removed (if I submit this patch, should I include that or add it
    to a second patch - that's the common approach in this community?).
    - Given the aforementioned comment on sql.Open, it's not entirely
    clear if DB instances should always be created via sql.Open directly. If
    they are, then the patch is correct setting maxIdleConns during
    construction of the struct in sql.Open, if not, then more work is required
    to handle the default in MaxIdleConns() where a value of 0 will be treated
    as 2, if bullet 1 is to remain. This latter approach would be unfortunate,
    because there are some real world use cases for 0 being a meaningful value.
    - It might be useful separately from a maximum value, although
    related, to make the implementation act more like a pool (at least
    optionally). Right now driver.Conn.Open() is left with the only recourse of
    panic when a database server is for example, run out of socket resources.
    It seems that Go has all the ability to create this scenario with ease.

    On to the Good News:
    *
    *
    The attached patch, as imperfect as it may be, does take the Go
    implementation of Collins Go-And-Java test[1] far beyond the Java
    implementation. You can find my fork on github[2], and some specific
    results in the README.md[3]

    16kr/s for Go, and 10kr/s for Java. I'm sure the Java version could be
    optimized at least somewhat. Both applications pretty much hose the CPU of
    my now quite warm Macbook Pro. The remote side (executing wrk(1)) was a mac
    mini with the machines attached between a Gigabit network running MTU 9000.
    There are a few more details in the README, but I'm sure I missed relevant
    items. The next bottleneck appears to be context switching - I was sharing
    the application machine with the Postgresql forks, and the test was
    generating more than 50% sys load under tension.

    Anyone should be happy with these results (including the Java/Dropwizard
    results). They're very good, and clearly demonstrate that for any generally
    normal real world application, the infrastructure and libraries in use will
    certainly not be the cause of any statistically significant latency.

    The last round of tests, on which this numbers are based, came from
    "f4a92d7eeb8d" with the attached patch applied.

    Thanks,

    James

    [1]
    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/
    [2] https://github.com/raggi/go-and-java
    [3]
    https://github.com/raggi/go-and-java/blob/master/README.md#example-results
    --
  • James Tucker at Sep 30, 2012 at 11:56 pm
    Thanks. I will repost there. Interestingly, contributing.html points at
    this list.
    On Sunday, September 30, 2012, Job van der Zwan wrote:

    It's obvious that you've put a lot of thought into this. However, this is
    intended more as a "general discussion" section of the Go language (as
    exemplified by the fact that I hardly understand what you're talking about,
    other than the fact that it involves databases and benchmarks). I think
    that you should try the developer group:

    https://groups.google.com/forum/?fromgroups=#!forum/golang-dev

    I'm sure you'll get more feedback there.

    In any case, welcome!

    On Monday, 1 October 2012 00:21:42 UTC+2, (unknown) wrote:

    Hi all,

    I took some time after getting bored being stuck at home sick, to poke the
    boundary benchmark a little more. I was disappointed with Go's
    representation in the test as well as the numbers displayed overall. In my
    experience both platforms should perform better, but in Go's case, there
    were "first 5 minutes" indicators of restricting factors. It turns out that
    Go's apparent poor performance was due to an innocent hardcoded value in
    database/sql. The most minimal patch conceived simply changes the value
    from 2 to 8 or 10, and most of the performance that can be attained then
    will be. In fact, against tip, I was able to take it much higher than that
    (with a tuned postgresql.conf), to hundreds of connections. Be thankful
    it's using a pure Go database driver.

    Apologies for the slightly inflammatory subject line. It's just for
    entertainment.

    The real reason for this mail, prior to submitting the patch, is that the
    specific approach in the patch could come under some discussion. The
    attached diff is probably the "minimal sane" patch that could be applied,
    but I have a few items worth discussing. If little discussion comes of it,
    I will submit this patch for now, and consider sending additional work if I
    can make the time for it. As I am new to this community, I don't yet know
    what style of patches are desired. If incremental, sane but incidental
    changes such as the attached patch are acceptable, I will start pushing
    them through.

    Here are my own review thoughts on the patch and surrounding issues:

    - The current code defaults to 2 "idle connections". In reality this
    equates to 2 "active connections" for various reasons. This default value
    is continued only such that users would not be subject to unexpected
    semantic changes.
    - There is no maximum limit implemented. While not the subject of this
    problem or patch, this should be implemented.
    - The immediate close behavior (something I am tempted to consider a
    bug) has not been altered. This point may become more of a philosophical
    discussion. In my experience, it's better to handle bursts with grace where
    possible. If this discussion becomes lit, it may be best to split it to
    another thread.
    - Related to the immediate close behavior, with or without changing
    that aspect, I feel that the pool could be rewritten with channels and
    goroutines. An almost example lives here (https://github.com/**
    eventmachine/eventmachine/**blob/master/lib/em/pool.rb<https://github.com/eventmachine/eventmachine/blob/master/lib/em/pool.rb>)
    (for those of you with very high attention to detail: yes, that contains
    some races that are easier to eradicate in a Go style environment).
    - If a channel approach is not taken, it may yet still make sense to
    at least move the mutex in database/sql to a RW variant with a persistent
    store of Conn objects and a free / use list. This should allow
    simplification of the Close anti-race logic. "defer" helps with this stuff,
    but, it's not showing itself to be a magic bullet.
    - The second comment on Open suggests that drivers will implement an
    Open that returns a *DB. This is no longer the case, and this comment
    should be removed (if I submit this patch, should I include that or add it
    to a second patch - that's the common approach in this community?).
    - Given the aforementioned comment on sql.Open, it's not entirely
    clear if DB instances should always be created via sql.Open directly. If
    they are, then the patch is correct setting maxIdleConns during
    construction of the struct in sql.Open, if not, then more work is required
    to handle the default in MaxIdleConns() where a value of 0 will be treated
    as 2, if bullet 1 is to remain. This latter approach would be unfortunate,
    because there are some real world use cases for 0 being a meaningful value.
    - It might be useful separately from a maximum value, although
    related, to make the implementation act more like a pool (at least
    optionally). Right now driver.Conn.Open() is left with the only recourse of
    panic when a database server is for example, run out of socket resources.
    It seems that Go has all the ability to create this scenario with ease.

    On to the Good News:
    *
    *
    The attached patch, as imperfect as it may be, does take the Go
    implementation of Collins Go-And-Java test[1] far beyond the Java impleme
    --
  • Dave Cheney at Oct 1, 2012 at 12:06 am
    I believe that is an error, I have raised
    http://code.google.com/p/go/issues/detail?id=4178
    On Mon, Oct 1, 2012 at 9:56 AM, James Tucker wrote:
    Thanks. I will repost there. Interestingly, contributing.html points at this
    list.
    On Sunday, September 30, 2012, Job van der Zwan wrote:

    It's obvious that you've put a lot of thought into this. However, this is
    intended more as a "general discussion" section of the Go language (as
    exemplified by the fact that I hardly understand what you're talking about,
    other than the fact that it involves databases and benchmarks). I think that
    you should try the developer group:

    https://groups.google.com/forum/?fromgroups=#!forum/golang-dev

    I'm sure you'll get more feedback there.

    In any case, welcome!

    On Monday, 1 October 2012 00:21:42 UTC+2, (unknown) wrote:

    Hi all,

    I took some time after getting bored being stuck at home sick, to poke the
    boundary benchmark a little more. I was disappointed with Go's
    representation in the test as well as the numbers displayed overall. In my
    experience both platforms should perform better, but in Go's case, there
    were "first 5 minutes" indicators of restricting factors. It turns out that
    Go's apparent poor performance was due to an innocent hardcoded value in
    database/sql. The most minimal patch conceived simply changes the value from
    2 to 8 or 10, and most of the performance that can be attained then will be.
    In fact, against tip, I was able to take it much higher than that (with a
    tuned postgresql.conf), to hundreds of connections. Be thankful it's using a
    pure Go database driver.

    Apologies for the slightly inflammatory subject line. It's just for
    entertainment.

    The real reason for this mail, prior to submitting the patch, is that the
    specific approach in the patch could come under some discussion. The
    attached diff is probably the "minimal sane" patch that could be applied,
    but I have a few items worth discussing. If little discussion comes of it, I
    will submit this patch for now, and consider sending additional work if I
    can make the time for it. As I am new to this community, I don't yet know
    what style of patches are desired. If incremental, sane but incidental
    changes such as the attached patch are acceptable, I will start pushing them
    through.

    Here are my own review thoughts on the patch and surrounding issues:

    The current code defaults to 2 "idle connections". In reality this equates
    to 2 "active connections" for various reasons. This default value is
    continued only such that users would not be subject to unexpected semantic
    changes.
    There is no maximum limit implemented. While not the subject of this
    problem or patch, this should be implemented.
    The immediate close behavior (something I am tempted to consider a bug)
    has not been altered. This point may become more of a philosophical
    discussion. In my experience, it's better to handle bursts with grace where
    possible. If this discussion becomes lit, it may be best to split it to
    another thread.
    Related to the immediate close behavior, with or without changing that
    aspect, I feel that the pool could be rewritten with channels and
    goroutines. An almost example lives here
    (https://github.com/eventmachine/eventmachine/blob/master/lib/em/pool.rb)
    (for those of you with very high attention to detail: yes, that contains
    some races that are easier to eradicate in a Go style environment).
    If a channel approach is not taken, it may yet still make sense to at
    least move the mutex in database/sql to a RW variant with a persistent store
    of Conn objects and a free / use list. This should allow simplification of
    the Close anti-race logic. "defer" helps with this stuff, but, it's not
    showing itself to be a magic bullet.
    The second comment on Open suggests that drivers will implement an Open
    that returns a *DB. This is no longer the case, and this comment should be
    removed (if I submit this patch, should I include that or add it to a second
    patch - that's the common approach in this community?).
    Given the aforementioned comment on sql.Open, it's not entirely clear if
    DB instances should always be created via sql.Open directly. If they are,
    then the patch is correct setting maxIdleConns during construction of the
    struct in sql.Open, if not, then more work is required to handle the default
    in MaxIdleConns() where a value of 0 will be treated as 2, if bullet 1 is to
    remain. This latter approach would be unfortunate, because there are some
    real world use cases for 0 being a meaningful value.
    It might be useful separately from a maximum value, although related, to
    make the implementation act more like a pool (at least optionally). Right
    now driver.Conn.Open() is left with the only recourse of panic when a
    database server is for example, run out of socket resources. It seems that
    Go has all the ability to create this scenario with ease.

    On to the Good News:

    The attached patch, as imperfect as it may be, does take the Go
    implementation of Collins Go-And-Java test[1] far beyond the Java impleme
    --
    --
  • Daniel Theophanes at Oct 1, 2012 at 1:33 am
    I like this patch. Make sure your code review goes to bradfitz. A few
    suggestions:
    In SetMaxIdleConns(), make sure you assign a positive number.

    Possibly in driver/driver.go, add a new interface called something like
    DefaultMaxIdleConnections, then in sql.go in Open() see if the driver
    implements it and get the value from that. if not implemented use 2.

    ... My input usually doesn't seem to carry much weight, so take with a
    grain of salt. :)
    -Daniel

    On Sunday, September 30, 2012 3:21:42 PM UTC-7, James Tucker wrote:

    Hi all,

    I took some time after getting bored being stuck at home sick, to poke the
    boundary benchmark a little more. I was disappointed with Go's
    representation in the test as well as the numbers displayed overall. In my
    experience both platforms should perform better, but in Go's case, there
    were "first 5 minutes" indicators of restricting factors. It turns out that
    Go's apparent poor performance was due to an innocent hardcoded value in
    database/sql. The most minimal patch conceived simply changes the value
    from 2 to 8 or 10, and most of the performance that can be attained then
    will be. In fact, against tip, I was able to take it much higher than that
    (with a tuned postgresql.conf), to hundreds of connections. Be thankful
    it's using a pure Go database driver.

    Apologies for the slightly inflammatory subject line. It's just for
    entertainment.

    The real reason for this mail, prior to submitting the patch, is that the
    specific approach in the patch could come under some discussion. The
    attached diff is probably the "minimal sane" patch that could be applied,
    but I have a few items worth discussing. If little discussion comes of it,
    I will submit this patch for now, and consider sending additional work if I
    can make the time for it. As I am new to this community, I don't yet know
    what style of patches are desired. If incremental, sane but incidental
    changes such as the attached patch are acceptable, I will start pushing
    them through.

    Here are my own review thoughts on the patch and surrounding issues:

    - The current code defaults to 2 "idle connections". In reality this
    equates to 2 "active connections" for various reasons. This default value
    is continued only such that users would not be subject to unexpected
    semantic changes.
    - There is no maximum limit implemented. While not the subject of this
    problem or patch, this should be implemented.
    - The immediate close behavior (something I am tempted to consider a
    bug) has not been altered. This point may become more of a philosophical
    discussion. In my experience, it's better to handle bursts with grace where
    possible. If this discussion becomes lit, it may be best to split it to
    another thread.
    - Related to the immediate close behavior, with or without changing
    that aspect, I feel that the pool could be rewritten with channels and
    goroutines. An almost example lives here (
    https://github.com/eventmachine/eventmachine/blob/master/lib/em/pool.rb)
    (for those of you with very high attention to detail: yes, that contains
    some races that are easier to eradicate in a Go style environment).
    - If a channel approach is not taken, it may yet still make sense to
    at least move the mutex in database/sql to a RW variant with a persistent
    store of Conn objects and a free / use list. This should allow
    simplification of the Close anti-race logic. "defer" helps with this stuff,
    but, it's not showing itself to be a magic bullet.
    - The second comment on Open suggests that drivers will implement an
    Open that returns a *DB. This is no longer the case, and this comment
    should be removed (if I submit this patch, should I include that or add it
    to a second patch - that's the common approach in this community?).
    - Given the aforementioned comment on sql.Open, it's not entirely
    clear if DB instances should always be created via sql.Open directly. If
    they are, then the patch is correct setting maxIdleConns during
    construction of the struct in sql.Open, if not, then more work is required
    to handle the default in MaxIdleConns() where a value of 0 will be treated
    as 2, if bullet 1 is to remain. This latter approach would be unfortunate,
    because there are some real world use cases for 0 being a meaningful value.
    - It might be useful separately from a maximum value, although
    related, to make the implementation act more like a pool (at least
    optionally). Right now driver.Conn.Open() is left with the only recourse of
    panic when a database server is for example, run out of socket resources.
    It seems that Go has all the ability to create this scenario with ease.

    On to the Good News:
    *
    *
    The attached patch, as imperfect as it may be, does take the Go
    implementation of Collins Go-And-Java test[1] far beyond the Java
    implementation. You can find my fork on github[2], and some specific
    results in the README.md[3]

    16kr/s for Go, and 10kr/s for Java. I'm sure the Java version could be
    optimized at least somewhat. Both applications pretty much hose the CPU of
    my now quite warm Macbook Pro. The remote side (executing wrk(1)) was a mac
    mini with the machines attached between a Gigabit network running MTU 9000.
    There are a few more details in the README, but I'm sure I missed relevant
    items. The next bottleneck appears to be context switching - I was sharing
    the application machine with the Postgresql forks, and the test was
    generating more than 50% sys load under tension.

    Anyone should be happy with these results (including the Java/Dropwizard
    results). They're very good, and clearly demonstrate that for any generally
    normal real world application, the infrastructure and libraries in use will
    certainly not be the cause of any statistically significant latency.

    The last round of tests, on which this numbers are based, came from
    "f4a92d7eeb8d" with the attached patch applied.

    Thanks,

    James

    [1]
    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/
    [2] https://github.com/raggi/go-and-java
    [3]
    https://github.com/raggi/go-and-java/blob/master/README.md#example-results
    --
  • Minux at Oct 1, 2012 at 3:24 pm

    On Oct 1, 2012 8:06 AM, "Dave Cheney" wrote:
    I believe that is an error, I have raised
    http://code.google.com/p/go/issues/detail?id=4178
    i think what's missing in the docs is how to select the correct mailing
    list to use (not
    eveything should be sent to golang-nuts/golang-dev).

    here is my suggestion based on my observations:
    1. trivial changes: docs typo for example, CL directly to golang-dev
    (I'd like to restrict this class to docs only)
    2. new features/new API/syntax etc (everything that might affect the
    language user):
    discuss at golang-nuts
    3. performance enhancements/optimizations (won't affect normal user except
    being
    more performant): discuss at golang-dev, CL is ok if you don't mind it
    being rejected
    4. if if you're not sure which mailing list to send, just send to
    golang-nuts to be safe.

    maybe we can add something like this to doc/contribution.html or go-wiki.

    --
  • James Tucker at Oct 5, 2012 at 5:16 am
    In this case, as there's been little to no movement here, I'll move this to
    a CL with a reasonable size bundle of first changes, and see what happens
    there.
    On Monday, October 1, 2012 8:24:31 AM UTC-7, minux wrote:


    On Oct 1, 2012 8:06 AM, "Dave Cheney" <da...@cheney.net <javascript:>>
    wrote:
    I believe that is an error, I have raised
    http://code.google.com/p/go/issues/detail?id=4178
    i think what's missing in the docs is how to select the correct mailing
    list to use (not
    eveything should be sent to golang-nuts/golang-dev).

    here is my suggestion based on my observations:
    1. trivial changes: docs typo for example, CL directly to golang-dev
    (I'd like to restrict this class to docs only)
    2. new features/new API/syntax etc (everything that might affect the
    language user):
    discuss at golang-nuts
    3. performance enhancements/optimizations (won't affect normal user except
    being
    more performant): discuss at golang-dev, CL is ok if you don't mind it
    being rejected
    4. if if you're not sure which mailing list to send, just send to
    golang-nuts to be safe.

    maybe we can add something like this to doc/contribution.html or go-wiki.
    --
  • Minux at Oct 5, 2012 at 5:21 am

    On Oct 5, 2012 1:16 PM, "James Tucker" wrote:
    In this case, as there's been little to no movement here, I'll move this
    to a CL with a reasonable size bundle of first changes, and see what
    happens there.
    i should have made this clear in my last post. for this case, i think
    sending cl directly to -dev is reasonable.

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 30, '12 at 10:21p
activeOct 5, '12 at 5:21a
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase