Unzip Map and IntMap more efficiently #164
Closed
+66
−6
Conversation
This file contains hidden or 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
The previous `Map` (same for `IntMap` throughout) instance would first map eagerly over tha `Map`, producing an entire `Map` full of thunks to apply the `unzipWith` function. Then it would build two more entire `Map`s full of thunks to select components of each pair. Depending on inlining and such, the resulting maps may or may not have contained selector thunks; if not, they could leak memory. Fix that. NOTE: This PR is an alternative to haskellari#163. This one preserves the precise laziness properties of the previous implementation.
Collaborator
|
I don't understand what happens here. I'll be happier if |
Author
|
I've opened haskell/containers#1174 to address this upstream. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The previous
Map(same forIntMapthroughout) instancewould first map eagerly over tha
Map, producing an entireMapfull of thunks to apply theunzipWithfunction. Thenit would build two more entire
Maps full of thunks to selectcomponents of each pair. Depending on inlining and such, the
resulting maps may or may not have contained selector thunks;
if not, they could leak memory. Fix that.
NOTE: This PR is an alternative to #163. This one preserves
the precise laziness properties of the previous implementation.