Che: Compare rendering performance terminal widget vs CommandOutputConsole.

[AndrienkoAleksandr]

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

• [x] terminal widget should be used for rendering command output in read only mode.
• [x] compare performance terminal rendering command output vs CommandOutputConsole
• [x] check if it is possible to use terminal "attach" plugin for bufferization output and check performance again.
• [x] create Orion based widget to render command output and check performance.

[AndrienkoAleksandr]

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 |

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

[benoitf]

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

[AndrienkoAleksandr]

I think we should do it in the frame of the issue https://github.com/eclipse/che-lib/issues/57