-
Notifications
You must be signed in to change notification settings - Fork 14.2k
Update ModuleSummaryIndexBitcodeReader::makeCallList reserve amount #95461
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
Conversation
Tighten the reserve() to `Record.size() / 2` instead of `Record.size()` in the HasProfile/HasRelBF cases (or even / 3 for IsOldProfileFormat). This reduces peak memory during ThinLTO indexing by ~3% in one example. Alternatively, we could reserve and then shrink_to_fit(), but seemed like we should just reserve the right amount (though that is a little more complex code).
and add shrink_to_fit in case of drift in the future (should be a no-op in the exact/common case).
@minglotus-6 would you be able to review this? (noticed this while looking at indexing memory usage) Thanks! |
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.
Sorry, I didn't notice this PR (until I searched my name in pull-request list).
lgtm.
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.
Nice find!
// Edge. Otherwise, conservatively reserve up to Record.size and later | ||
// shrink_to_fit when we are done (and shrink_to_fit for the exact | ||
// case should be a no-op). | ||
if (!IsOldProfileFormat && (HasProfile || HasRelBF)) { |
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 don't think we should be optimizing for the old profile format which is very legacy at this point. I think the shrink_to_fit is only needed in that case - is that correct?
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.
Thanks for taking a look! Yes, shrink_to_fit is only needed in the legacy case right now.
A reason I had added it was as a safeguard in case the format changed in the future, but the reserve()
parts weren't updated. Then it would provide a bit of protection.
Otherwise, I am happy to remove the shrink_to_fit too.
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.
Ok, removed the shrink_to_fit and simplified the comment a bit.
No worries, thanks for taking a look and helping add reviewers! |
// case should be a no-op). | ||
if (!IsOldProfileFormat && (HasProfile || HasRelBF)) { | ||
Ret.reserve(Record.size() / 2); | ||
} else |
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.
In this case the braces for the "then" branch can be removed per https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
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.
Done
We aren't interested in optimizing for the old formats.
…lvm#95461) Tighten the reserve() to `Record.size() / 2` instead of `Record.size()` in the HasProfile/HasRelBF cases. For the uncommon old profile format cases we leave it as is, but those should be rare and not worth optimizing. This reduces peak memory during ThinLTO indexing by ~3% in one example. Alternatively, we could make the branching for reserve more complex and try to cover every case.
Tighten the reserve() to
Record.size() / 2
instead ofRecord.size()
in the HasProfile/HasRelBF cases. For the uncommon old profile format cases we leave it as is, but those should be rare and not worth optimizing.This reduces peak memory during ThinLTO indexing by ~3% in one example.
Alternatively, we could make the branching for reserve more complex and try to cover every case.