Reduce memory footprint by reusing buffers #229
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit changes mongoSocket.Query to reuse allocated []byte buffers by getting and putting then into a sync.Pool. Also the function MarshalBuffer was added to the bson package and the addBSON function now uses it. It behaves in the exact same way to Marshal but instead of allocating a []byte buffer it receives an already existing buffer. Benchmarks show a really nice decrease in memory footprint specially when large messages are being sent to MongoDB, as is the case of inserting multiple documents at once. $ benchcmp before.txt after.txt benchmark old ns/op new ns/op delta BenchmarkInsertSingle-4 94191 90779 -3.62% BenchmarkInsertMultiple-4 1076423 937569 -12.90% benchmark old allocs new allocs delta BenchmarkInsertSingle-4 50 46 -8.00% BenchmarkInsertMultiple-4 456 242 -46.93% benchmark old bytes new bytes delta BenchmarkInsertSingle-4 2472 1320 -46.60% BenchmarkInsertMultiple-4 191180 29228 -84.71%
|
Today I figured a way to simplify the code and improve even more the benchmarks. I've already updated the commits and the benchmark result comparison on the original comment. |
|
That's nice. I've been meaning to look into buffer reuse, but always thought about the harder case which is unmarshaling. This is a much easier win. Will need a few tweaks since we should expose that via an interface such as bson.NewEncoder instead of MarshalBuffer, but I can tweak that on my end. |
wpjunior
pushed a commit
to wpjunior/mgo
that referenced
this pull request
Aug 12, 2018
* Add 3.6 user authenticationRestrictions * Add struct-field comment * Add struct-field comment go-mgo#2 * Add struct-field comment go-mgo#3 * Add documentation link * Fix comment * Fix comment go-mgo#2 * add to README.md * add to README.md go-mgo#2 * add to README.md go-mgo#3 * Add positive/negative authentication restrictions user test * Use denyUser for negative test * Correct message * Fix error match * Fix close on nil/closed session * Simplify test, last change :) * Simplify test, last change :) go-mgo#2 * Simplify test, last change :) go-mgo#3 * Fix := error
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds some benchmarks for
Collection.Insert()and changesmongoSocket.Query()andaddBSON()to reuse allocated[]bytebuffers by getting and putting then into async.Pool.Also the function
MarshalBufferwas added to the bson package. It behaves in the exact same way as Marshal but instead of allocating a []byte buffer it receives an already existing buffer.I came upon these changes after profiling a real world application that inserts a lot of documents simultaneously.
The added benchmarks show a really nice decrease in memory footprint specially when large messages are being sent to MongoDB, as is the case of inserting multiple documents at once:
I did't use gocheck for the benchmarks because it was returning some weird numbers. I'm not sure whether I did something wrong but these are the numbers for the exact same code only adapting it to use gocheck:
Compared to the use of native benchmarks:
Maybe I did something wrong and I'm open to work on it further if you have any tips.