Experiment - do not pass state and input between steps by sergei-shabanau · Pull Request #81 · spartanz/parserz

sergei-shabanau · 2020-04-02T15:52:34Z

⚠️
Interesting code here:

final def parser[S, E, A] function in ParserModule2
InOut.scala
changes to the test.

The rest is a copy-paste of existing code, please ignore it.
⚠️

Trying the following:

consuming from Array[Char]
thus not having interim Input created
using mutable state instead of passing and returning state at every step

The parser signature currently is (ignore the S parameter):

final def parser[S, E, A](grammar: Grammar[S, S, E, A]): Input => E \/ A

I tested the code in the perf test for parsing JSON that I use as a base line to compare with FastParse.

I have an improvement over previous design: 1,000,000 runs in ~15 sec vs ~25 sec as before. This is not great as FastParse does it in ~4 sec 😐

What do I have extra compared to FastParse?

Either returned at ever step
traversal of grammar during execution
recursive and polymorphic step function call

From what I found while working on this part, polymorphic functions did the the biggest contribution to lower performance.

jdegoes · 2020-04-02T18:51:36Z

src/main/scala/org/spartanz/parserz/InOut.scala

+      class S(var read: Int, var res: Boolean)
+
+      ManyConditional(
+        new Mutable[E, Array[Char], Array[Char]] {


Try to use simple by storing a bit into the Int for the boolean flag and using the rest of the bits for read.

Sure, thanks for the hint!
This specific instance is neglected because it has very limited effect on my perf test result.

jdegoes · 2020-04-02T18:52:14Z

src/main/scala/org/spartanz/parserz/InOut.scala

+        final def needsMoreInput(s: State): Boolean = !s.done
+
+        final def feed(s: State, input: Array[Char], i: Int): Int = {
+          val last = input.indexWhere(!p(_), i)


Be aware that methods of Array are, in some cases, radically slower than Chunk, because many Array extension methods get the default iterable implementation.

Thanks!
I even tried to use code from Java 🙂
In fact, I'll try Chunk instead of Array now and see if makes any difference.

Regarding Array methods I use here, Chunk has same implementations 👍

jdegoes · 2020-04-02T18:52:58Z

src/main/scala/org/spartanz/parserz/ParsersModule2.scala

+  final def parser[S, E, A](grammar: Grammar[S, S, E, A]): Input => E \/ A =
+    input => step(grammar, new ParserState(input, 0, Nil))
+
+  private def step[S, E, A](grammar: Grammar[S, S, E, A], ps: ParserState[E]): E \/ A =


Step should throw E values inside an exception type that does NOT store stack traces, to eliminate the overhead of Either boxing on each step.

@jdegoes
I did some experiments with this function.

Throwing exception instead of returning Either (basically as control flow) is about 2.5 times slower.

Returning null or A instead of Either is about 5% faster - hard to measure accurately.

The biggest perf improvement I had with this function so far is by avoiding lambdas and curried function signatures, specifically having a function with one parameters list returning a value (as opposed to several parameter lists and returning a function).

What type of exception did you throw? With a stack trace or without?

Here's what I would suggest: rewrite step to be a while loop. Then you don't need Either or exceptions. You can use a product encoding of the either: a nullable variable that could be an error; and another nullable variable that could be the success.

@jdegoes
Exception without stack trace

private object ParserError extends Throwable with NoStackTrace

I already tried returning null or value instead of using Either or exception, it is only about 5% difference, not significant.

I don't think while loop is possible since I need to analyze values produced by parts of alt and zip 🤔
But even if it is, what is the advantage? I am basically reimplementing Java call stack, but all the code is the same, based on megamorphic function - the feature removed in FastParse 2. BTW, my current design is similar to FastParse 1 and sacrificing it made ~4x improvements possible in FastParse 2 😉

I have uploaded the latest code.

We could try to eliminate the megamorphic functions. To do that we have to eliminate all lambdas and runtime functions such as those appearing in Codec.

Essentially we'd be building a language for constructing data (case class / sealed trait). The language would including filtering, comparisons, basic math, etc. Then we can compile the parser to anything, including bytecode on the JVM.

How fast do you want to go? 😄

jdegoes · 2020-04-02T19:08:32Z

src/main/scala/org/spartanz/parserz/ParsersModule2.scala

+        }
+        ret
+
+      case zip: Grammar.GADT.ZipL[S, S, E, ta, tb] =>


Good that you specialized ZipL / ZipR 👍

jdegoes · 2020-04-02T19:09:16Z

src/main/scala/org/spartanz/parserz/ParsersModule2.scala

+            else Left(e)
+        }
+
+      case zip: Grammar.GADT.Zip[S, S, E, ta, tb] =>


This should be replaced by ZipAll so we can eliminate intermediate allocations (nested tuples).

For sure!
I tested it before, and the overhead in this specific perf test is minimal. Currently I'm trying improvements in isolation but eventually I will merge all the work together.

jdegoes · 2020-04-02T19:09:47Z

src/main/scala/org/spartanz/parserz/ParsersModule2.scala

+          case Right(_) => step(zip.right, ps)
+        }
+
+      case alt: Grammar.GADT.Alt[S, S, E, ta, tb] =>


This should be replaced by AltAll so we can eliminate intermediate allocations (nested eithers).

jdegoes · 2020-04-02T19:10:40Z

src/main/scala/org/spartanz/parserz/ParsersModule2.scala

+  final def parser[S, E, A](grammar: Grammar[S, S, E, A]): Input => E \/ A =
+    input => step(grammar, new ParserState(input, 0, Nil))
+
+  private def step[S, E, A](grammar: Grammar[S, S, E, A], ps: ParserState[E]): E \/ A =


Add @tailrec after the deletion of Either return value.

I don't think it's possible due to alt and zip - I need to examine the returned values of several branches.

sergei-shabanau added 3 commits April 1, 2020 16:13

#77 - Consume from Array

1d3a451

#77 - Not passing functions around

7969f5d

#77 - Not passing state around

a02a04f

sergei-shabanau mentioned this pull request Apr 2, 2020

Reading/Writing (binary) data zio-archive/zio-codec#4

Closed

jdegoes reviewed Apr 2, 2020

View reviewed changes

sergei-shabanau added 2 commits April 3, 2020 12:07

#77 - Bitwise logic instead of mutable state

d0c8125

#77 - null or value instead of Either

065855d

sergei-shabanau mentioned this pull request Apr 8, 2020

Compile parser into bytecode zio-archive/zio-codec#5

Closed

Conversation

sergei-shabanau commented Apr 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sergei-shabanau commented Apr 2, 2020 •

edited

Loading