Parser performance improvements with repeated inputs #14

Open
opened 2 years ago by tdeeb · 0 comments
tdeeb commented 2 years ago (Migrated from github.com)
Owner

Repeated inputs currently get expanded out into multiple inputs. If an input consists of "[a . b .]*2", it gets expanded to "a . b . a . b .". For many repetitions and longer messages (Ex. 999), the original message string can get extremely large.

This drastically affects the parser's performance since regex expressions take long to parse with such a large string.

One idea for improving this would be to not expand the sequence to begin with. There'd be some sort of marker for when the repetition starts and when it ends. For example, in "[a . b .]*2", the repetition starts at input index 0 and ends at 3. This would have to account for nested inputs as well (Ex. "[a . [b .]*2 #500ms]*4").

Then, using the repetition information, the InputHandler would simply repeat the inputs while carrying them out. This should cut down on parsing while allowing repeated inputs. This will require a significant refactor and a lot of testing, so we should plan it out and write some tests.

Repeated inputs currently get expanded out into multiple inputs. If an input consists of `"[a . b .]*2"`, it gets expanded to `"a . b . a . b ."`. For many repetitions and longer messages (Ex. 999), the original message string can get extremely large. This drastically affects the parser's performance since regex expressions take long to parse with such a large string. One idea for improving this would be to not expand the sequence to begin with. There'd be some sort of marker for when the repetition starts and when it ends. For example, in `"[a . b .]*2"`, the repetition starts at input index 0 and ends at 3. This would have to account for nested inputs as well (Ex. `"[a . [b .]*2 #500ms]*4"`). Then, using the repetition information, the `InputHandler` would simply repeat the inputs while carrying them out. This should cut down on parsing while allowing repeated inputs. This will require a significant refactor and a lot of testing, so we should plan it out and write some tests.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.