Chunked output

[kseistrup]

Commands that produce ‘many’ lines and bytes of output (e.g., ps faux: 26+ kB in 200+ lines) seem to become displayed in chunks of approximately 4 kB bytes, temporally spaced ~1 second apart when run in an mtm pane, while the same output appears virtually instantly without mtm.

The textmode editor jed takes approximately 5 seconds to initialize its display in an mtm pane, all the while the cursor jumps to different positions appr. every second. The same initialization takes place instantly without mtm.

Displaying a 256 line ASCII file with 128 chars per line (including line terminator) in pagers more, less and most exhibits the same chunkiness in mtm.

The funny thing is, that while the above is also true while recording the session with asciinema (to illustrate what I see), replaying the recorded file does not show the chunked output when replayed outside of mtm.

All of this happens on a local machine, there is no network involved.

mtm: 1.0 and 1.0.1 OS: ArchLinux x86_64 glibc: 2.29 ncurses: 6.1 Window manager: qtile Terminal emulator: sakura, lilyterm or xterm Shell: fish or bash $TERM: xterm-256color (before starting mtm, screen-256color inside mtm) $LANG: en_DK.UTF-8 $LC_ALL: en_DK.UTF-8 $COLUMNS: 191 $LINES: 60

[deadpixi]

I think I've figured out the issue. Excess screen update traffic is being sent, but it's not noticeable at the number of rows/columns that I normally run things at. Get the terminal big enough and the slowdown is apparent.

@kseistrup Would you try out the latest master, please? I've reduced the amount of screen update traffic, and things appear significantly faster.

[kseistrup]

This is way better than before: I don't notice any chunks.

However, the output in mtm is noticeably slower than in a plain terminal.

$ # Without mtm
$ time ps faux
0.01user 0.02system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 4288maxresident)k
0inputs+0outputs (0major+355minor)pagefaults 0swaps
$ mtm
$ # With mtm
$ time ps faux
0.01user 0.02system 0:00.13elapsed 28%CPU (0avgtext+0avgdata 4252maxresident)k
0inputs+0outputs (0major+353minor)pagefaults 0swaps

The times varies a bit, but the nummbers above look representative for several runs. Interesting with the difference in CPU percentages.

[nwmcsween]

Run perf w and w/o mtm to see what is happening

[deadpixi]

@kseistrup I've made a few more speedups, but I think we may have hit a plateau.

For the sake of simplicity, mtm uses ncurses pads to implement scrollback. I checked out the implementation of scrolling in ncurses and it's not designed to be fast. It operates under the assumption that the things being scrolled will have tens of lines and tens of columns -- not 200 columns and 1000 lines.

I'll investigate how difficult it would be to use a different scrollback mechanism, but it'd be a pretty big change.

Either way, please check out the latest master. There should be some additional slight speedups.

[kseistrup]

@deadpixi it is still noticeably slower than a plain terminal emulation. It's not a big problem, but I thought you should know. The chunked output is gone and that's good.