slow text output on Windows #740
Comments
|
grepping the log for Something else you may wish to try is eliminating python buffering/performance concerns; redirect the output of your python script to a file, then |
|
|
|
Grepping for After printing After this all elapsed sequences look very similar with these lines, repeated every 600~ line feeds or so (After printing ..., At exit: Summing all the paint_impl elapsed time in the entire log results in 6906.4 ms |
|
ConPTY is the WIndows PTY layer. It is implemented as a separate helper process called I ran a variation on your test; outputting the python script to a text file and
The bottom two are faster because ConPTY isn't involved. I also tried running "Windows Terminal": powershell -> type: felt like it took closer to 20 seconds to me (about 4-5x slower than wezterm) My conclusion from this is that the bottleneck is the windows pty layer and not wezterm itself. I'd recommend that you consider using https://wezfurlong.org/wezterm/multiplexing.html#connecting-into-windows-subsystem-for-linux if you plan on regularly outputting large quantities of text. |
wez
changed the title
|
Here is a more thorough investigation/exploration for only printing a log file that contains 100'000 lines: Local computer
Local computer
Local computer, WSL
SSH to remote Linux machine (ping latency 4 ms)
With tmux all of the terminals above performed a lot faster! Cygwin is the clear winner |
|
So connected over ssh and attached to the same tmux3.1b session cygwin is
Running
Could it be that the sluggish printing from python causes wezterm to have time to draw the screen more times resulting in slower rendering in total? How does cygwin speed this up? |
wez
added a commit
that referenced
this issue
Apr 29, 2021
This has the effect of reducing the memory and scroll cost for lines that are shorter than the physical width of the terminal matrix. refs: #740
wez
added a commit
that referenced
this issue
Apr 29, 2021
In the situation where we have a full screen terminal (eg: 500 cells wide), but very little output (eg: only 10's of columns on the left are NOT blank), we would previously spend a non-trivial amount of time calculating fg/bg colors for the blanks that trailed the actual clusters; the calculation for each row was: O(trailing-blanks * full cell color compute cost) which was around 30us per row. For large numbers of rows this could add up to >10ms per frame. This commit changes the logic to run in two phases: * O(selection-width) with simple fg/bg color updates for the selection range * O(1) full cell color compute cost for the cursor if the cursor is somehow in the trailing blank region and not already handled by the earlier clustering logic. With the sequence of recent commits, the frame time for the large terminal case has been reduced from ~22ms to ~7ms, which is approx 3x improvement. refs: #740
wez
added a commit
that referenced
this issue
Apr 30, 2021
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
I am running a simple python script that prints the numbers from 0 to 99_999 and the rendering time and sometimes also the runtime of that is really long in wezterm (up to 45 seconds in Full screen which is about 90x490 characters in font size 9)
Starting WSL and running the python script on the local machine gives this output:
Which corresponds to the render time which is about 10 seconds. (using my phone as a timer)
If I run the same script on a remote Linux machine that I ssh to the rendering time i 5 seconds (a little bit better!) and output is:
So the render time in this case is much longer compared to what
timereports.Environment (please complete the following information):
default_prog = {"wsl"}To Reproduce
Python script
tmp.py:Command to benchmark:
Trace log from
WEZTERM_LOG=traceParts of the trace are available here: https://pastebin.com/uQJ1n9k6
Beginning of script output:
Middle
End of output:
Expected behavior
Faster rendering
The text was updated successfully, but these errors were encountered: