[knutwannheden]

After #2876, the largest remaining lookahead cost in parsing performance.sql sits in the callers of ComplexExpressionList(): ExpressionList() ran three 3-token LOOKAHEAD(3) probes to choose between the complex, simple and parenthesed list forms, and ParenthesedExpressionList() scanned into the list to decide whether its body is empty. Together they took about 5% of parser CPU, net of lexing, and both decisions have a token-level answer.

The three probes in ExpressionList() decided nothing, because ComplexExpressionList() accepts every list the other two forms do:

• Expression() accepts every SimpleExpression(), so the simple form is a subset.
• Its probe walks Expression() → PrimaryExpression() → "(" → ParenthesedExpressionList(), the same tokens the parenthesed probe walks, and PrimaryExpression()'s subselect alternatives are semantic guards that hold inside a scan as well.

So the complex alternative won wherever either of the others could have, and the fallback alternative behind the probes, added in ca2b3d7 for bracketed operands such as ( 1 + a ) / ( 1 + b ), was the same production once more. ExpressionList() now calls ComplexExpressionList() directly.

ParenthesedExpressionList()'s optional body is now [ LOOKAHEAD({ getToken(1).kind != CLOSING_BRACKET }) ComplexExpressionList() ]. Anything else that is not a list start fails inside Expression() instead of at the ), as in #2876. JavaCC drops that semantic guard inside nested scans, so the saving is on the parse path, where the profile samples were.

Which alternative wins matters for the AST: the block after the choice re-wraps a plain list holding one parenthesed list, but returns a parenthesed list holding one as it is. The reasoning above says the complex alternative already won in every case that parsed, and the full suite agrees.

FunctionTest.testBracketedOperandAndEmptyListArguments pins the two shapes only the removed alternatives looked responsible for, f((1 + a) / (1 + b), (c + d) * 2) and f(()), which ca2b3d7 shipped without a test, plus VALUES () for a list that reaches ExpressionList() outside a function call.

Parser-thread CPU per parse against #2876 (e8243dc), three interleaved pairs of JVMs, 200 warmup and 300 measured parses each:

pair	#2876	this branch
1	29.05 ms	27.68 ms
2	28.80 ms	27.41 ms
3	29.15 ms	28.04 ms

./gradlew jmh -PjmhProfiler=gc on the same machine, #2876 first:

	#2876	this branch	5.4
time	32.67 ± 1.17 ms/op	28.54 ± 0.70 ms/op (−12.6%)	49.22 / 47.43 ms/op
gc.alloc.rate.norm	7,166,820 B/op	7,165,980 B/op	7,767,975 / 7,771,902

The 5.4 control moved 3.6% between the two runs, so the CPU table above is the conservative figure; the direction is the same in both.

This branch is based on master after #2876 merged; the baseline column above was taken on #2876's branch commit e8243dc, which is the same tree as its merge commit a0e0861. It also rewords one comment that #2876 adds in ComplexExpressionList(), and the JMH pair was taken on an earlier iteration whose only difference is a fallback alternative that ran when the parser was interrupted.

[manticore-projects]

Thank you very much!