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
Cumulation optimization #280
Conversation
Seems like the speed and memory usage is really good.. See: |
buf.writeBytes(input); | ||
} else { | ||
// wrap the cumulation and input | ||
buf = ChannelBuffers.wrappedBuffer(cumulation, input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't use a composite buffer - it's known to perform pretty bad and it will make hotspot confused because of one more ChannelBuffer implementation to consider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also just use a HeapChannelBuffer but I'm not sure this would be good in terms of memory usage and speed (byte copies)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized that your change limits the number of components in the composite buffer to 2. Because the number of components are very small, I think it might be OK.
@trustin so ok to pull in ? |
Yes, once buffer factory issues are fixed. |
Ah, could we compare the performance between the composite buffer version and the heap buffer version? |
Let me try to write one but Tim's perf tests are promising with CompositeChannelBuffer |
Yeah, I just wonder if it's gonna be even faster with the heap buffer. Could you ask Time for the numbers? :-) |
We'll have to rewrite this part when we switch to a heap buffer.
|
Why? |
@trustin Tim tried his benchmark also with HeapChannelBuffer but he saw no speed improvements. So I think we should merge it like it is |
Make the cumulation usage more memory efficient
I see. Thanks! |
This changes try to minimize the size of the cumulation buffer to a minimum. Before we used a DynamicChannelBuffer which was never "shrinked" again. The problem with the previous implementation was that it could lead to very big cumulation buffers.
For example if you receive a buffer with 65k it will create a cumulation buffer with min. 65k + whatsleft. If you are lucky enough you will even get a cumulation buffer of 2 * 65k as the DynamicChannelBuffer will double its size if it needs more room.
The changes here try to fix it.
@trustin please review