Faster and more correct eagerization. #9
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
container types. The eagerization is now 4 times faster, and can handle eagerizing Clojure deftype and Java Arrays. It can also properly eagerize container's who's .toString or print-method have been modified in a way which does not visit the elements.
Closed
This is 3x faster then cond, and is now open for extenssion, so if users have custom container types, they can simply extend them to support eagerize and it will work fine with special. For some reason, it doesn't work to extend object arrays for subtypes, so I had to implement it as part of the java.lang.Object case.
|
Bump, have you ever looked into this? I had already forgot about it myself 😛 , but if you don't find anything wrong with it, I think it would be a good addition to Special. |
damienstanton
added a commit
to damienstanton/special
that referenced
this pull request
Jul 29, 2023
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.
I improved eagerization by directly handling all Clojure and Java container types. The eagerization is now around 20 times faster, and can handle
eagerizing Clojure deftype, delays and Java Arrays. It can also properly
eagerize container's who's .toString or print-method have been modified
in a way which does not visit the elements.
After all the conversations, I thought I'd give it a go. I think with this, there's no need to offer pluggable eagerization, since I don't see any scenario where someone's eagerizing needs would not be covered by this.
This also sets things up to continually improve eagerization over time. In case a new edge case is found, or performance is still an issue.
EDIT: I've re-implemented it using protocols. So the way I did it, eagerization is extensible by users. So they don't even need to wait on the maintainers to add custom container types or override any of the logic used to eagerize. I still doubt there will be much need for this, but we get it for free because of protocols, as well as a massive performance boost, so its win/win.