Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/gob: can it avoid unsafe? #5159

Closed
robpike opened this issue Mar 29, 2013 · 5 comments
Closed

encoding/gob: can it avoid unsafe? #5159

robpike opened this issue Mar 29, 2013 · 5 comments

Comments

@robpike
Copy link
Contributor

robpike commented Mar 29, 2013

How much would performance be affected if encoding/gob did not use unsafe? Its use of
unsafe predates considerable support offered in later implementations of reflect. It
might work well today using only reflection without too much overhead, although struct
manipulation might still hurt.

The fundamental issue is indexing into a struct by field offset/index. Unsafe allows us
to move a pointer; reflection requires more work. How much?
@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 1:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 2:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 3:

Labels changed: added repo-main.

@gopherbot
Copy link

Comment 4:

CL https://golang.org/cl/102680045 mentions this issue.

@robpike
Copy link
Contributor Author

robpike commented Jun 30, 2014

Comment 5:

This issue was closed by revision 3050a0a.

Status changed to Fixed.

@robpike robpike self-assigned this Jun 30, 2014
@golang golang locked and limited conversation to collaborators Jun 24, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
This removes a major unsafe thorn in our side, a perennial obstacle
to clean garbage collection.
Not coincidentally: In cleaning this up, several bugs were found,
including code that reached inside by-value interfaces to create
pointers for pointer-receiver methods. Unsafe code is just as
advertised.

Performance of course suffers, but not too badly. The Pipe number
is more indicative, since it's doing I/O that simulates a network
connection. Plus these are end-to-end, so each end suffers
only half of this pain.

The edit is pretty much a line-by-line conversion, with a few
simplifications and a couple of new tests. There may be more
performance to gain.

BenchmarkEndToEndByteBuffer     2493          3033          +21.66%
BenchmarkEndToEndPipe           4953          5597          +13.00%

Fixes golang#5159.

LGTM=rsc
R=rsc
CC=golang-codereviews, khr
https://golang.org/cl/102680045
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
This removes a major unsafe thorn in our side, a perennial obstacle
to clean garbage collection.
Not coincidentally: In cleaning this up, several bugs were found,
including code that reached inside by-value interfaces to create
pointers for pointer-receiver methods. Unsafe code is just as
advertised.

Performance of course suffers, but not too badly. The Pipe number
is more indicative, since it's doing I/O that simulates a network
connection. Plus these are end-to-end, so each end suffers
only half of this pain.

The edit is pretty much a line-by-line conversion, with a few
simplifications and a couple of new tests. There may be more
performance to gain.

BenchmarkEndToEndByteBuffer     2493          3033          +21.66%
BenchmarkEndToEndPipe           4953          5597          +13.00%

Fixes golang#5159.

LGTM=rsc
R=rsc
CC=golang-codereviews, khr
https://golang.org/cl/102680045
@rsc rsc unassigned robpike Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants