Skip to content
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

Optimize arity wrapper for << and >> #1145

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jfmengels
Copy link
Contributor

Prior to this, << (and similarly >>) would be compiled to

var $elm$core$Basics$composeL = F3(function (g, f, x) { ... })

which doesn't match the call sites, which is always of the shape

A2($elm$core$Basics$composeL, f, g)

This change makes it so that composeL/composeR are now wrapped with A2, which improves the performance by about 30%.


Here is the benchmark that I have been using: https://github.com/jfmengels/elm-benchmarks/blob/master/src/WhatIsFaster/FunctionComposition.elm (where I compare >> and lambdas)

Prior to the change:
Screenshot from 2024-07-01 17-11-47

After the change:
Screenshot from 2024-07-01 17-12-32


A further improvement to this (not in this PR, and more in the scope of the compiler would be to replacing A2(composeL, f, g) by composeL(f, g):
Screenshot from 2024-07-01 17-13-14


PS: At some point in the past, the Elm compiler turned composition into lambdas, but it removed that in elm/compiler@6ae0168.

Prior to this, << (and similarly >>) would be compiled to

  var $elm$core$Basics$composeL = F3(function (g, f, x) { ... })

which doesn't match the call sites, which is always of the shape

  A2($elm$core$Basics$composeL, f, g)

This change makes it so that composeL/composeR are now wrapped with A2,
which improves the performance by about 30%.
Copy link

Thanks for suggesting these code changes. To set expectations:

  • Pull requests are reviewed in batches, so it can take some time to get a response.
  • Smaller pull requests are easier to review. To fix nine typos, nine specific issues will always go faster than one big one. Learn why here.
  • Reviewers may not know as much as you about certain situations, so add links to supporting evidence for important claims, especially regarding standards for CSS, HTTP, URI, etc.

Finally, please be patient with the core team. They are trying their best with limited resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant