-
Notifications
You must be signed in to change notification settings - Fork 185
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
Don't reallocate buffers in fragment consolidation #4614
Conversation
e87bdeb
to
b5334e7
Compare
Apparently you can just tag a comment with the sc-##### in brackets and it links to the story. |
[sc-36372] |
This pull request has been linked to Shortcut Story #36372: create_buffers taking large percentage of time during consolidation. |
b5334e7
to
9f25912
Compare
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'm not convinced that calling resize
is better than destroying and recreating the workspace. If the sizes don't change (maybe for shortening), then sure, it'll be more efficient. On the other hand, lengthening will often require a memory copy because vector::resize
preserves all the existing members before the operation.
vector
does default-initialization (setting to zero) as well as copies on resize. Do we need either of these behaviors from the container? Would uninitialized memory work? The first thing we're doing is writing into them with query results. Is there some expectation that the buffer be initialized with zero to work correctly?
9f25912
to
14176de
Compare
ff75159
to
d1fa68f
Compare
d1fa68f
to
5746668
Compare
This is based on the work from @Shelnutt2 on branch `ss/sc-36372`.
5746668
to
2c5cbbe
Compare
Avoid needless buffer reallocations when consolidating fragments.
TYPE: IMPROVEMENT
DESC: Avoid needless buffer reallocations when consolidating fragments.