bithero-rust/ninox-parser
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Rework LR helper crate #2

New issue
Open
opened 2026-01-01 12:47:22 +01:00 by mai-lapyst · 0 comments
mai-lapyst commented 2026-01-01 12:47:22 +01:00
Owner
Copy link

Problem

Currently the LR helper crate is quite wastefull:

  1. It represents alternatives as seperate rules, which by itself isnt that problematic (it actualy saves us an vec for each alternation inside an rule), but
  2. All rule names are Strings, allocated & owned by an rule, which wastes memory for alternations due to many allocated strings.
  3. All terminals (as well as non-terminals) inside rules are ALSO Strings which wastes more memory.
  4. It dosnt support any higher features so repetition and so forth would need to "linearized" to fit into the model, adding more rules and thus more allocated strings.

While one could argue that this dosn't matter that much rn, since the tool currently is used at compiletime to generate rust code, it does so by using an proc-macro which will potentially get re-run every time a compile task is started. Also it hurts any tool trying to use it at runtime (i.e. I want to build an playground some day).

Solutions:

Either wrap rules inside Rc to have multiple references or use rule indezies / IDs to refer to them internally. Same for terminals: we dont actually need an string representation to build the tables, since they only store IDs anyway.

## Problem Currently the LR helper crate is quite wastefull: 1. It represents alternatives as seperate rules, which by itself isnt that problematic (it actualy saves us an vec for each alternation inside an rule), but 2. All rule names are `String`s, allocated & owned by an rule, which wastes memory for alternations due to many allocated strings. 3. All terminals (as well as non-terminals) inside rules are ALSO `String`s which wastes more memory. 4. It dosnt support any higher features so repetition and so forth would need to "linearized" to fit into the model, adding more rules and thus more allocated strings. While one could argue that this dosn't matter that much rn, since the tool currently is used at compiletime to generate rust code, it does so by using an proc-macro which will potentially get re-run every time a compile task is started. Also it hurts any tool trying to use it at runtime (i.e. I want to build an playground some day). ## Solutions: Either wrap rules inside `Rc` to have multiple references or use rule indezies / IDs to refer to them internally. Same for terminals: we dont actually need an string representation to build the tables, since they only store IDs anyway.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
bithero-rust/ninox-parser#2
No description provided.