-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support typed array in parser #1796
Conversation
da7020d
to
06e8954
Compare
@Tyriar At least it runs fast 😊 |
@Tyriar Should be fixed now, problem was that I mixed up the input data array with the result concat array. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after the String.fromCharCode.apply
change is done. I think we should hold off on this until 3.9.0 goes out as it hasn't had any real testing yet.
@Tyriar Yeah we can hold it back, also it will not show its real potential until we switched over to typed array only buffer. |
I think we should hold this back until 3.11, it does not make much sense with the JS Array based buffer lines. |
@jerch sounds good, try to periodically merge in changes so the branches don't diverge too much |
…js into typedarray_parser
Part one - the transition to UTF32 parser buffer is done. Here are some speed numbers from xterm-benchmark:
Almost every testcase doubles the throughput rate, PRINT is even 8 times faster. The lame ducks are those sequences that do an interim string conversion, esp. ESC % G, which uses '%G' for a property lookup, seems multi char strings are not any good as property keys? Up for review. Next steps (in separate PRs):
|
…js into typedarray_parser
@Tyriar Did some more cleanup, ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Onwards!
This PR moves the parser to typed array support instead of JS strings.
Changes the internal API for the
parse
method, the print handler and the DCS handler.Parser speedup: runtime from 120 ms down to 45 ms (
ls -lR /use/lib
)With a later change of the
BufferLine
API this enables the possibility to completely remove any string processing fromInputHandler.print
, which will give the input chain another nice speedup (>50%). This is not possible until we removed the JSArray variant ofBufferLine
.It also opens the possibility to evaluate other array buffer based input encodings later on.
Part of #791.