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.

Sign up for GitHub

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

Jump to bottom

transport: allocate bigger slabs and reuse #587

Merged
merged 1 commit into from
Apr 4, 2016
Merged

transport: allocate bigger slabs and reuse #587

merged 1 commit into from
Apr 4, 2016

Conversation

tamird
Copy link
Contributor

@tamird tamird commented Mar 6, 2016

This provides a substantial speed improvement with large payloads.

name                 old time/op    new time/op    delta
GRPCServeHTTP_1K-4      178µs ± 2%     177µs ± 1%     ~     (p=1.000 n=5+5)
GRPCServeHTTP_64K-4    1.30ms ± 3%    1.09ms ± 4%  -16.82%  (p=0.008 n=5+5)

name                 old speed      new speed      delta
GRPCServeHTTP_1K-4   11.5MB/s ± 2%  11.6MB/s ± 1%     ~     (p=1.000 n=5+5)
GRPCServeHTTP_64K-4   100MB/s ± 2%   121MB/s ± 4%  +20.26%  (p=0.008 n=5+5)

name                 old alloc/op   new alloc/op   delta
GRPCServeHTTP_1K-4     88.5kB ± 0%    93.9kB ± 0%   +6.16%  (p=0.008 n=5+5)
GRPCServeHTTP_64K-4     801kB ± 0%     791kB ± 0%   -1.16%  (p=0.008 n=5+5)

name                 old allocs/op  new allocs/op  delta
GRPCServeHTTP_1K-4        162 ± 0%       156 ± 0%   -3.70%  (p=0.008 n=5+5)
GRPCServeHTTP_64K-4       645 ± 0%       284 ± 0%  -55.96%  (p=0.016 n=5+4)

Benchmarked using https://github.com/cockroachdb/rpc-bench.

@iamqizhao @bradfitz

@tamird
Copy link
Contributor Author

tamird commented Mar 7, 2016

Updates #586.

@tamird tamird mentioned this pull request Mar 7, 2016
Merged
@bradfitz
Copy link
Contributor

@iamqizhao, I am against this change for a number of reasons:

  1. it does too many unrelated things in one pull request
  2. the first commit ("isItem is ...") has a poor commit message subject and actually does two things. One is okay (but unrelated to performance), and the other I disagree with its direction (value vs pointer receivers) even though I agree with making things consistent.
  3. the handler_server.go change is not safe. It touches code around a TODO without addressing the TODO.

I think 1) alone is enough to reject this request. The pieces can be submitted separately for independent review, but it's too much distraction trying to review them together.

@iamqizhao
Copy link
Contributor

I agree. I simply had no idea what is going on with this PR. I remember you had some comments in this PR but could not find them any more.

@bradfitz
Copy link
Contributor

My comments were deleted when this pull request was updated. Because Github totally sucks for code review.

I think we should switch gRPC 100% to Gerrit at some point.

@tamird
Copy link
Contributor Author

tamird commented Mar 28, 2016

Some of this PR was extracted into #588, which should be more digestible.
I'll rebase this once that PR is decided, and it will contain just one
commit.
On Mar 28, 2016 19:20, "Brad Fitzpatrick" notifications@github.com wrote:

My comments were deleted when this pull request was updated. Because
Github totally sucks for code review.

I think we should switch gRPC 100% to Gerrit at some point.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#587 (comment)

@tamird
Copy link
Contributor Author

tamird commented Mar 29, 2016

Closing this for now.

@tamird tamird closed this Mar 29, 2016
@tamird
transport: allocate bigger slabs and reuse
9e8752e 
This provides a substantial speed improvement with large payloads.

Benchmarked using https://github.com/cockroachdb/rpc-bench:

```
name                 old time/op    new time/op    delta
GRPCServeHTTP_1K-4      178µs ± 2%     177µs ± 1%     ~     (p=1.000 n=5+5)
GRPCServeHTTP_64K-4    1.30ms ± 3%    1.09ms ± 4%  -16.82%  (p=0.008 n=5+5)

name                 old speed      new speed      delta
GRPCServeHTTP_1K-4   11.5MB/s ± 2%  11.6MB/s ± 1%     ~     (p=1.000 n=5+5)
GRPCServeHTTP_64K-4   100MB/s ± 2%   121MB/s ± 4%  +20.26%  (p=0.008 n=5+5)

name                 old alloc/op   new alloc/op   delta
GRPCServeHTTP_1K-4     88.5kB ± 0%    93.9kB ± 0%   +6.16%  (p=0.008 n=5+5)
GRPCServeHTTP_64K-4     801kB ± 0%     791kB ± 0%   -1.16%  (p=0.008 n=5+5)

name                 old allocs/op  new allocs/op  delta
GRPCServeHTTP_1K-4        162 ± 0%       156 ± 0%   -3.70%  (p=0.008 n=5+5)
GRPCServeHTTP_64K-4       645 ± 0%       284 ± 0%  -55.96%  (p=0.016 n=5+4)
```
@tamird tamird reopened this Mar 29, 2016
@tamird tamird changed the title transport: performance improvements transport: allocate bigger slabs and reuse Mar 29, 2016
@tamird
Copy link
Contributor Author

tamird commented Mar 29, 2016

Updated; just one commit here now.

@bradfitz
Copy link
Contributor

LGTM. @iamqizhao?

I still want to delete all this code, but this is fine and better for now.

@tamird
Copy link
Contributor Author

tamird commented Apr 1, 2016

@iamqizhao ping

@iamqizhao
Copy link
Contributor

The PR's description is out-dated. need either update.

@tamird
Copy link
Contributor Author

tamird commented Apr 1, 2016

Huh? Looks up-to-date to me.

iamqizhao
iamqizhao reviewed Apr 1, 2016
View reviewed changes
transport/handler_server.go
}
if err != nil {
s.buf.put(&recvMsg{err: mapRecvMsgError(err)})
return
}
if len(buf) == 0 {
buf = make([]byte, readSize)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? the next iteration will do anyways (line 319).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the loop on line 319 only runs buf := make(...) once, and each iteration exhausts some of the front of buf until it's gone. This refills it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ugh, I misread.

@tamird
Copy link
Contributor Author

tamird commented Apr 4, 2016

@iamqizhao ping.

@iamqizhao iamqizhao merged commit 466b6e4 into grpc:master Apr 4, 2016
@tamird tamird deleted the perf branch April 4, 2016 19:45
@lock lock bot locked as resolved and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@tamird @bradfitz @iamqizhao