[kvlonge]

Why

Parsing dominates SQL lint cost in downstream users: tokenize plus parse is about two thirds of lint instructions. Profiling showed per-token hashing for single character tokens, a full token copy when parsing from kept tokens, and heavy memcpy because every Expression was 232 bytes due to the unboxed Star variant.

Changes

• Tokenizer: array lookups for single character tokens and identifier quotes instead of hashing per token.
• Parser::with_config_from_tokens(sql, &[Token], config) builds parser tokens that share kept token text instead of cloning the token vector.
• Breaking (Rust API): Expression::Star now holds Box<Star>, shrinking Expression from 232 to 96 bytes. Construct it with Expression::Star(Box::new(star)) or Expression::star(). Pattern matches on Expression::Star(_) are unaffected. Serde output is unchanged because Box<T> serializes like T, so JSON, Python, WASM and FFI ASTs keep the same shape.

Verification

• Lint batch of 2,249 requests: instructions 12.94 G to 11.17 G (about 14 percent fewer), CPU about 1.60 s to 1.35 s. Diagnostics byte-identical with default rules and with all 53 rules enabled.
• Downstream compile of a 3,000 model project: wall 6.47 s to 6.07 s, CPU 15.05 s to 13.54 s, RSS flat. Compile JSON and compiled output identical; compiler differential over 391 projects passed.
• Downstream Rust workspace tests: 1,057 passed. Downstream Python unit and integration tests: 11,727 passed; 6 signal timing failures reproduce identically without this change.
• Local cargo fmt --check and cargo check -p polyglot-sql --tests pass. The full polyglot suite could not compile locally (8 GB memory), so this draft relies on CI for core, release-fixtures, bindings and feature-gates.