⚡ Bolt: Optimize character matching speed in luaparse.js#26
Conversation
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
Pull request overview
This PR optimizes hot-path character matching in luaparse.js by replacing several indexOf-based membership checks with direct equality / charCodeAt comparisons, aiming to improve lexer/parser throughput.
Changes:
- Replaced several single-character
'<chars>'.indexOf(x) >= 0checks with===comparisons andcharCodeAt()comparisons. - Updated unary operator and table field-separator checks to use explicit equality comparisons.
- Added an internal
.jules/bolt.mdnote documenting the optimization rationale.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| luaparse.js | Reworks several character-membership checks in numeric literal parsing and a couple parser/utility checks for speed. |
| .jules/bolt.md | Adds documentation/notes about the micro-optimization approach and intended usage guidance. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if ((input.charCodeAt(index) === 105 || input.charCodeAt(index) === 73)) { | ||
| ++index; | ||
| return true; |
| if ((input.charCodeAt(index) === 117 || input.charCodeAt(index) === 85)) { | ||
| ++index; | ||
| if ('lL'.indexOf(input.charAt(index) || null) >= 0) { | ||
| if ((input.charCodeAt(index) === 108 || input.charCodeAt(index) === 76)) { | ||
| ++index; | ||
| if ('lL'.indexOf(input.charAt(index) || null) >= 0) { | ||
| if ((input.charCodeAt(index) === 108 || input.charCodeAt(index) === 76)) { |
| } else if ((input.charCodeAt(index) === 108 || input.charCodeAt(index) === 76)) { | ||
| ++index; | ||
| if ('lL'.indexOf(input.charAt(index) || null) >= 0) { | ||
| if ((input.charCodeAt(index) === 108 || input.charCodeAt(index) === 76)) { | ||
| ++index; |
| if ((input.charCodeAt(index) === 112 || input.charCodeAt(index) === 80)) { | ||
| foundBinaryExponent = true; | ||
| ++index; | ||
|
|
||
| // Sign part is optional and defaults to 1 (positive). | ||
| if ('+-'.indexOf(input.charAt(index) || null) >= 0) | ||
| if ((input.charCodeAt(index) === 43 || input.charCodeAt(index) === 45)) | ||
| binarySign = ('+' === input.charAt(index++)) ? 1 : -1; |
| @@ -0,0 +1,3 @@ | |||
| ## 2024-05-23 - luaparse string matching optimization | |||
💡 What: Optimized character lookups in
luaparse.jsby replacingString.prototype.indexOfchecks with strict equality (===) andcharCodeAtlogic.🎯 Why: In hot execution paths inside lexers and parsers, single character lookups using string indexing methods like
'xX'.indexOf(char) >= 0are relatively slow. Using.charCodeAt()directly avoids allocating new string primitives for single characters and operates faster. Out-of-bounds.charCodeAt()returnsNaN, which safely acts as false when evaluating strict equality===, eliminating the need for|| nullfallback checks.📊 Impact: The
npm run bench:luastbenchmarks show an improvement in parser throughput:This results in roughly a 3.4% overall increase in raw parse speed. Since it is in a core tokenization loop, the impact aggregates well.
🔬 Measurement:
npm run testto verify parser compliance and ensuring there's zero functional regressions.npm run bench:luastto witness the speedups.PR created automatically by Jules for task 9511892538594208665 started by @ericbfriday