Grow large arrays more slowly #11482
Merged
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
|
@mgomes do you want to continue this? Can you add some specs testing the capacity growth? |
|
@beta-ziliani Thanks for the early review! Sorry I pushed up a draft because I couldn't get the test suite to run locally. If you don't mind waiting a couple more days (it's a holiday here) I'd love to push this one to the finish line. |
straight-shoota
approved these changes
Nov 27, 2021
asterite
reviewed
Nov 29, 2021
| @@ -52,6 +52,12 @@ class Array(T) | |||
| # Size of an Array that we consider small to do linear scans or other optimizations. | |||
| private SMALL_ARRAY_SIZE = 16 | |||
|
|
|||
| # The initial capacity reserved for new arrays; just a lucky number | |||
This pull request was closed.
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.
Fixes #11445
This introduces the heuristic found in Go for re-sizing arrays. For arrays < 256 elements, the heuristic doubles array capacities as before. For arrays >= 256, it starts to limit the growth of re-sizes. It does so in a linear fashion until around ~20k elements at which it limits array growth to ~25%.
I've included a couple specs showing the progression of the array growth with the new heuristic, but let me know if we should include more progressions. I was just concerned about memory usage.
Progression examples: