Skip to content
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

Compare rendering performance terminal widget vs CommandOutputConsole. #7029

Closed
4 tasks done
AndrienkoAleksandr opened this issue Oct 27, 2017 · 3 comments
Closed
4 tasks done
Assignees
Labels
kind/task Internal things, technical debt, and to-do tasks to be performed.

Comments

@AndrienkoAleksandr
Copy link
Contributor

AndrienkoAleksandr commented Oct 27, 2017

Description
Compare rendering performance terminal widget vs CommandOutputConsole
What should be done:

  • terminal widget should be used for rendering command output in read only mode.
  • compare performance terminal rendering command output vs CommandOutputConsole
  • check if it is possible to use terminal "attach" plugin for bufferization output and check performance again.
  • create Orion based widget to render command output and check performance.
@AndrienkoAleksandr AndrienkoAleksandr added kind/task Internal things, technical debt, and to-do tasks to be performed. team/enterprise labels Oct 27, 2017
@AndrienkoAleksandr AndrienkoAleksandr self-assigned this Oct 27, 2017
@tolusha tolusha added status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. sprint/current labels Oct 30, 2017
@AndrienkoAleksandr AndrienkoAleksandr added status/in-progress This issue has been taken by an engineer and is under active development. and removed status/open-for-dev An issue has had its specification reviewed and confirmed. Waiting for an engineer to take it. labels Nov 7, 2017
@AndrienkoAleksandr
Copy link
Contributor Author

AndrienkoAleksandr commented Nov 14, 2017

Conclusions

I completed comparing the performance of current CommandOutput widget and widget based on xterm.js and widget based on Orion. During investigation I created widgets based on xterm.js and Orion. For all widgets I set up scroll-back size 5000 lines. For test I used rendering of an output from a file and received this output with the help of a custom command. This command reads n lines from a huge file (40148 lines). Each step I changed the amount of lines (100, 200, 500, 1000, 2500, 5000, 10000) and measured the performance (full rendering time) with the help of Google Chrome Development tools. You can see the comparison in the table and the graphic (time in seconds):

Quantity lines 100 200 500 1000 2500 5000 10000
Console output widget 0.464 0.724 1.456 3.158 9.7 26.3138 49.2
Xterm.js based widget 0.384 0.514 0.756 1.198 2.67 3.974 5.684
Orion based widget 0.532 0.916 1.068 1.86 7.39 9.3 16.646

comparison_perfomance

On each step the fastest was xterm.js based widget, the second was Orion based widget, and the last one was current CommandOutputWidget. On the big output xterm.js was faster than current widget in 3-9 times. Attach plugin for terminal was designed for using with web-sockets so we can't use it to speed up terminal more.

Xterm.js (2.4.0)

Pluses: rendering performance, xterm.js contains control sequence parser (to display text colors, progressors, text-based user interface), contains auto scroll feature, linkify url feature.
Minuses: current version contains some ugly bugs, resize performance is not ideal(in the latest version should be better), we can not display text without a word wrap feature (but it's a normal behavior for terminal widget), like we do in the current widget.

Orion (14)

Pluses: better rendering performance than current CommandOutput widget for big output. Ability to turn on /off word wrap feature.
Minuses: seems we need to rework Orion injection mechanism to use this widget on start of the IDE to dispaly machine logs. It's quite a big change. Orion has no control sequence parser. Potentially we can apply such parser, like guys from Cloud 9 did it for their ICE editor (their terminal was "ICE editor" + "term.js" control sequence parser...). But it's a complex task. Vscode uses Monaco editor to render output without control sequence parser.

Branch with test code

@AndrienkoAleksandr AndrienkoAleksandr removed the status/in-progress This issue has been taken by an engineer and is under active development. label Nov 14, 2017
@benoitf
Copy link
Contributor

benoitf commented Nov 14, 2017

@AndrienkoAleksandr do you were able to test with Xterm.js 3 branch ?

@AndrienkoAleksandr
Copy link
Contributor Author

I think we should do it in the frame of the issue eclipse-che/che-lib#57

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/task Internal things, technical debt, and to-do tasks to be performed.
Projects
None yet
Development

No branches or pull requests

3 participants