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

reuse allocated buffer #271

Merged
merged 4 commits into from
Jul 6, 2021
Merged

Conversation

tylitianrui
Copy link
Contributor

What this PR does:
reuse allocated buffer when buffer size < 128 byte. it not only reuse allocated buffer , but also avoid memory leak.

@wongoo
Copy link
Contributor

wongoo commented Jun 29, 2021

@tylitianrui have u meet a memory leak issue? how it happens?

@codecov-commenter
Copy link

codecov-commenter commented Jun 29, 2021

Codecov Report

Merging #271 (21a0f63) into master (8dc4b20) will decrease coverage by 0.20%.
The diff coverage is 0.00%.

❗ Current head 21a0f63 differs from pull request most recent head 91610ac. Consider uploading reports for the commit 91610ac to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master     #271      +/-   ##
==========================================
- Coverage   67.44%   67.24%   -0.21%     
==========================================
  Files          26       26              
  Lines        2666     2674       +8     
==========================================
  Hits         1798     1798              
- Misses        649      657       +8     
  Partials      219      219              
Impacted Files Coverage Δ
encode.go 77.45% <0.00%> (-6.60%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8dc4b20...91610ac. Read the comment docs.

encode.go Outdated
@@ -50,7 +50,13 @@ func NewEncoder() *Encoder {

// Clean clean the Encoder (room) for a new object encoding.
func (e *Encoder) Clean() {
buffer := make([]byte, 64)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@wongoo Making a slice of byte have an advantage: avoiding memory leak caused by growth of underlying array . but making it , when call method Clean every time, is unnecessary too. the underlying array can be reused.
this PR, have two advantages:

  • reusing the buffer (reducing memory-allocation);
  • avoiding memory leak caused by growth of underlying array

@wongoo
Copy link
Contributor

wongoo commented Jun 30, 2021

@tylitianrui In concurrent scenario, an encoder encodes an object and gets a byte buffer, but async to process it. If u reuse the buffer, it may cause the data buffer being changed by other encoding process.

It may be better to create a new API, like Encoder.ReuseBufferClean , to tell user the clean will reuse the buffer.

@tylitianrui
Copy link
Contributor Author

@tylitianrui In concurrent scenario, an encoder encodes an object and gets a byte buffer, but async to process it. If u reuse the buffer, it may cause the data buffer being changed by other encoding process.

It may be better to create a new API, like Encoder.ReuseBufferClean , to tell user the clean will reuse the buffer.

YES, There is a risk of the buffer changed by other one

encode.go Outdated
// it reuse allocated buffer and reduce memory-allocation.
func (e *Encoder) ReuseBufferClean() {
var buffer []byte
if len(e.buffer) <= 128 {
Copy link
Contributor

Choose a reason for hiding this comment

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

does it need to check the buffer length?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i am sorry, i made a typo. cap , not len.

if not check the buffer capacity. there is a risk of memory leak. for example, an encoder encodes an huge object (eg: 100K ), the allocated room of buffer is also so big. generally, most of object is not such huge. it causes most of buffer room is not used and not GC . it is

128 may be too small for most situation,i suggest to change it to 512,or allow user to chang it by ‘hessian.SetReuseBufferSize(int)’

good idea

@wongoo
Copy link
Contributor

wongoo commented Jul 2, 2021

128 may be too small for most situation,i suggest to change it to 512,or allow user to chang it by ‘hessian.SetReuseBufferSize(int)’

@wongoo wongoo requested review from zouyx and fangyincheng July 5, 2021 01:59
@wongoo wongoo merged commit dad2892 into apache:master Jul 6, 2021
zhaoyunxing92 pushed a commit that referenced this pull request Sep 4, 2021
* reuse buffer  avoid allocate

* reuse buffer clean

* typo

* reuse buf size 512
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants