-
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
Performance of refresh is still subpar #134
Comments
@parisk I can have a go at fixing this considering I have the most context. |
@Tyriar I think that we are already skipping such refreshes in a6e85ad#diff-d4f745d6f29faa0617f2e02bb95f0c44R1206. Do you mean something else? Feel free to give it a try if you would like. What is the approach you are thinking to take? |
@parisk using a DocumentFragment to prevent layout thrashing. I believe right now if a refresh takes longer than 34ms, it may not wait before starting a new one, ie. |
I had the same problem with https://github.com/netzkolchose/jquery.browserterminal and played alot with performance tips floating around. What helped to increase the output performance and interactivity was:
|
Slightly offtopic: |
XOFF/XON solves the CTRL+C plus big input data problem as you can try with this patch: https://gist.github.com/jerch/4393f100562b602ee1cc030cc9fa1f63 |
Follow up from #131 (comment)
It looks like refresh and the layout is still taking far too long in a real application scenario. Consider the following portion of a Chromium timeline when running
ls -lR /usr/share
in VS Code, which takes around 3.5s for the process to run but ~25s until it's finished in the UI.My initial thoughts on this were that it was taking too long to parse the incoming data in
Terminal.prototype.write
but this timeline seems to refute that. All time is spent in refresh and functions/events it triggers.Here is the timeline for a single refresh:
And zoomed in even more to the portion of refresh that gets repeated:
The basic flow of the section that repeats is:
Looking at this, refresh's performance could still certainly be improved. In the meantime another thing that would be good to have to protect against this is to skip refreshes if a refresh is already in progress.
The text was updated successfully, but these errors were encountered: