Fix 1 ClangTidyPerformance finding:
* 'push_back' is called inside a loop; consider pre-allocating the container capacity before the loop For more info see go/clang_tidy/checks/performance-inefficient-vector-operation
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/clang-tidy-bug for category ClangTidyPerformance if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* For all other issues such as the formatting of the CL, please file a bug under
go/clrobot-bug.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/third_party/quiche/METADATA.common which is reachable following include_presubmits from //depot/google3/third_party/quic/METADATA by
following go/clrobot#how-to-opt-in. Anything wrong with the signup? File a bug
at go/clrobot-bug.
#clrobot #performance-inefficient-vector-operation
Tested:
Local presubmit tests passed.
PiperOrigin-RevId: 818950018
diff --git a/quiche/quic/core/quic_connection_id_manager.cc b/quiche/quic/core/quic_connection_id_manager.cc
index 74d3a51..0d8ed48 100644
--- a/quiche/quic/core/quic_connection_id_manager.cc
+++ b/quiche/quic/core/quic_connection_id_manager.cc
@@ -235,6 +235,7 @@
std::vector<uint64_t> QuicPeerIssuedConnectionIdManager::
ConsumeToBeRetiredConnectionIdSequenceNumbers() {
std::vector<uint64_t> result;
+ result.reserve(to_be_retired_connection_id_data_.size());
for (auto const& cid_data : to_be_retired_connection_id_data_) {
result.push_back(cid_data.sequence_number);
}
