-
-
Notifications
You must be signed in to change notification settings - Fork 247
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
the Parser migration from fastparse to cats-parse #650
Conversation
I think it worth to make some performance comparison between fastparse and cats-parse solution |
If it's going on? |
@timzaak I don't think there was much progress, in case you're interested to contribute ;) |
I tried, but cats-parse api is now very different from fastparse. Almostly need rewrite all the code. and need wait this issue: typelevel/cats-parse#186 Honestly, It's may be a good idea to wait fastparse support Scala 3. |
@timzaak @ghostdogpr I rewrote Parser with cats-parse but stuck with whitespace implementation. I will commit the last changes soon. |
cats-parse 0.3.1 has changed a lot comparing with 0.1 |
@lvitaly I changed a lot depends on your work. remove fastparse implemention of whitespace, and try to insert it in everywhere needed. So Sad. |
# Conflicts: # build.sbt # core/src/main/scala/caliban/parsing/Parser.scala
@lvitaly @ghostdogpr The performance would improve by handle PS:
|
I rewrite it, and it looks good to me, I don't know if it is good to replace fastparse, or just provide an alternative choice for GraphQL parse. |
@timzaak one thing that would be interesting is to run the caliban benchmark project with fastparse vs cats-parse. If there is not much difference maybe we could migrate entirely. If cats-parse is much slower maybe we only adopt it temporarily inside a "scala3" branch. |
Closing in favor of #850 |
Relates to #631