sync: decide whether to keep Pool #6984

Closed
rsc opened this Issue Dec 18, 2013 · 8 comments

Comments

Projects
None yet
3 participants
@rsc
Contributor

rsc commented Dec 18, 2013

We're going to add Pool early in the 1.3 cycle, but we should decide toward the end
whether it has been useful enough to stay.
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Dec 18, 2013

Contributor

Comment 1:

Also decide whether package sync is the right place.
Contributor

rsc commented Dec 18, 2013

Comment 1:

Also decide whether package sync is the right place.
@robpike

This comment has been minimized.

Show comment
Hide comment
@robpike

robpike Dec 18, 2013

Contributor

Comment 2:

Also delete the words about "experimental" if we decide to keep it.
Contributor

robpike commented Dec 18, 2013

Comment 2:

Also delete the words about "experimental" if we decide to keep it.
@robpike

This comment has been minimized.

Show comment
Hide comment
@robpike

robpike Dec 18, 2013

Contributor

Comment 3:

Labels changed: added repo-main.

Contributor

robpike commented Dec 18, 2013

Comment 3:

Labels changed: added repo-main.

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Jan 30, 2014

Comment 4 by Jens.Alfke:

+1. In developing the Couchbase Sync Gateway we've run into several situations where it
was difficult to cache expensive resources without bloating the GC heap. A GC-aware
cache like Pool would really help. (Haven't tried it yet, as we're still developing on
Go 1.2.) Please release it in 1.3.

Comment 4 by Jens.Alfke:

+1. In developing the Couchbase Sync Gateway we've run into several situations where it
was difficult to cache expensive resources without bloating the GC heap. A GC-aware
cache like Pool would really help. (Haven't tried it yet, as we're still developing on
Go 1.2.) Please release it in 1.3.
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Feb 6, 2014

Comment 5 by voidlogic7:

I've been using sync.Pool in my personal projects and it has been a huge performance
win. For me this has shifted the line where I decided what I can code in C and what I
can code in Go farther to Go's favor. If I revert from pool I see massive degradation
including an order of magnitude greater heap usage and what I think are GC pauses. Of
course I would never actually do that and if this went away I could still use some of
the custom pool's I used to use (or write in C), but their performance doesn't compare
favorably due to lack of thread-local pooling.

Comment 5 by voidlogic7:

I've been using sync.Pool in my personal projects and it has been a huge performance
win. For me this has shifted the line where I decided what I can code in C and what I
can code in Go farther to Go's favor. If I revert from pool I see massive degradation
including an order of magnitude greater heap usage and what I think are GC pauses. Of
course I would never actually do that and if this went away I could still use some of
the custom pool's I used to use (or write in C), but their performance doesn't compare
favorably due to lack of thread-local pooling.
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Mar 9, 2014

Comment 6 by uldericofilho:

I am the author of Gobloomd. I have been working on optimisations, among them the use of
pool of resources (sync.Pool).

Comment 6 by uldericofilho:

I am the author of Gobloomd. I have been working on optimisations, among them the use of
pool of resources (sync.Pool).
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Apr 3, 2014

Contributor

Comment 7:

sync.Pool is being kept. issue #7167 reminds us to make sure the docs are clear about
when it should be used (Rob to write the docs).
Contributor

rsc commented Apr 3, 2014

Comment 7:

sync.Pool is being kept. issue #7167 reminds us to make sure the docs are clear about
when it should be used (Rob to write the docs).
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Apr 3, 2014

Contributor

Comment 8:

Status changed to Fixed.

Contributor

rsc commented Apr 3, 2014

Comment 8:

Status changed to Fixed.

@rsc rsc added fixed labels Apr 3, 2014

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015

@rsc rsc removed the release-go1.3 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.