Parser microoptimizations

[kyri-petrou]

I was implementing a parser using fastparse today at $WORK and found out that CharsWhileIn("xx", minChars) is much more efficient than using .repX. With these changes we get ~5-10% performance increase in our ParserBenchmark.

Note that I also changed the fullIntrospectionQuery val to strip the margins of the query. I realised that we were benchmarking too heavily the whitespace parser

[ghostdogpr]

It doesn't match the spec definition (keeping the code close to the spec is good for maintainability), how about changing document instead?

[kyri-petrou]

I reverted the change. tbh it only makes a difference for invalid queries really

[ghostdogpr]

But how about changing document to (Start ~ definition.rep ~ End)? I agree with the fix, just wanted to do it somewhere else 😄

[kyri-petrou]

document is currently this:

((Start ~ executableDefinition.rep ~ End) | (Start ~ definition.rep ~ End)).map(seq => ParsedDocument(seq.toList))

The reason for having Start ~ executableDefinition.rep ~ End separately is so that when when we reach the end of the file after executableDefinition has successfully parsed (which is the most common thing we parse), we shortcut to the end and don't try typeSystemDefinition prior to exiting. I'm not sure if it's even possible, but in the case that there is a typeSystem definition in the query then we'll fallback to the full parser.

I actually realised that the "fix" I did earlier wouldn't work for cases that there is a mix of them; although I don't know if that's a valid query 🤔. If yes I should add a test for it

[ghostdogpr]

Ah, didn't know we were trying to be clever 🤣