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

evaluate static string matches in TypedExprNormalization #1262

Merged
merged 7 commits into from
Nov 20, 2024

Conversation

johnynek
Copy link
Owner

I noticed we are generating code for static string matches that could be done in advance.

This refactors to use the existing string matching code statically.

]
): Option[Expr] =
arg match {
case Literal(Lit.Str(s)) =>
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could extend this very easily to any Literal which is probably all we need to handle here.

That said, maybe this code should really be pushed into TypedExprNormalization since applying these optimizations could open other normalizations.

import org.scalacheck.Prop.forAll
import org.scalacheck.Gen

class StrPartTest extends munit.ScalaCheckSuite {
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this test actually also tests that all the matching algorithms agree. It seems we have something like 4 of them:

  1. StrPart
  2. SeqPattern + matcher
  3. NamedSeqPattern + matcher
  4. java regex

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think StrPart is the fastest, but I haven't carefully benchmarked it, but they should all agree, and the speed only matters for the MatchlessToValue runtime, in normalization, it doesn't matter I don't think.

@johnynek johnynek changed the title evaluate static string matches in matchless evaluate static string matches in TypedExprNormalization Nov 19, 2024
@johnynek johnynek merged commit 35cbe08 into main Nov 20, 2024
8 checks passed
@johnynek johnynek deleted the oscar/20241118_optimize_some_static_matches branch November 20, 2024 00:11
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