-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Collecting into a Result<Vec<_>> doesn't reserve the capacity in advance #48994
Copy link
Copy link
Open
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.C-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchCategory: An issue highlighting optimization opportunities or PRs implementing suchI-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.C-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchCategory: An issue highlighting optimization opportunities or PRs implementing suchI-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Couldn't find an issue for this and don't know if it counts but filing anyway.
If you have
the
SpecExtendmachinery ensures that the vector hass.len()space reserved in advance. However if you change it to return a resultthen (based on examining the LLVM IR and heaptracker's "Temporary" measurements) that optimization has quietly been lost.
This is technically correct in the sense that the first element yielded could be an
Errof course (the size hint for theAdapterinResult'sFromIteratorimpl has a lower bound of 0). But this pessimizes the good path to take more memory and be slower in favor of possibly saving memory on the bad one, which seems backwards.Is there a specialization that could be added to fix this?