-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(3230): remove curryX dependency for internal transducer creator functions #3231
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand your motivation. If I understand correctly your thinking is that the internal functions don't need to be curried because they are never called with their full arguments and always with the same set. So we could optimise by currying ourselves basically.
I think this is perfectly sensible but I need to get my head around _dispatchable
as this function seems key in order to conduct a review (at least for me).
Do you have an idea of how much we gain performance wise?
Overall I think this is pretty nice. Good catch!
I'm thinking deeply about it and I can say that technically it doesn't depends on
Because of composition of transducers we won't need another way of partial application over transducer creators. Then, it seems we will never need to wrap internal transducer creators with curryX functions.
I'm not sure how to check it. I've seen tables with benchmarks in #3048 but I don't know how they were created. Is there a standard way to create benchmarks in this project? Thanks |
Yep you're right. I mentioned We recently had this issue reported #3232 which seems to be a regression in I'd like another review from a maintainer if that's ok. |
OK, I have a solution for this issue. I can send a PR there. It's working too with this change. |
I've added these bench tests:
Original benchmarks:
With the change:
Do you think it could be interesting to add in the PR for testing transducer approach performance? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry to be slow on this one. I keep going to it, and seeing 24 changed files -- having to do with transducers, which I was never really a part of -- and saying, "Well, no time now. I'll look later."
I finally dug in to realize how simple a change this is. It makes perfect sense to me. The boost in performance is nice, but the code simplification is its biggest advantage.
Very nice! 🌿
From issue #3230
Notice that now transducer creator functions just depend on themselves after removing curryX functions. This could facilitate ramda modularity because now it's easier to create a library that works just with transducers without rely in other parts of the library.