Improve performance under memory pressure [was: All open terminals slow down if another visible window is outputting lots of output.]

If I have a visible window that is doing a lot of scrolling (in my case it's a lot of rsync output), it causes all other terminals to slowdown and only update at the rate of the "large output" terminal. To put it in another term, if you have a tab/window in a "pinwheel" state, that is it's printing some long running output (and showing a pinwheel in the tab), it causes all other tabs/windows to stop updating in real time, an dthey start updating when the pinwheel window does.

This is kind of odd to explain in words, so I've included a video to demonstrate what I mean. https://www.youtube.com/watch?v=eAR8yqc_2S4&feature=youtu.be

iTerm Version: 3.0 OS Version: 10.11.5

Here is my config file: com.googlecode.iterm2.plist

Here is my sample. Sample_of_iTerm2.txt

This does appear to be related to having unlimited scrollback enabled. It doesn't happen until data has been scrolling for a while, and if you edit the profile and limit the scrollback it'll immediately stop chugging so hard.

I wonder if you're using so much memory that you're thrashing swap. That was painfully slow redrawing.

I think we need to do something to improve performance under memory pressure, like shunting some of the scrollback buffer to disk.

Milestone changed to %Review for next version

Changed title: All open terminals slow down if another visible window is outputting lots of output. → Improve performance under memory pressure [was: All open terminals slow down if another visible window is outputting lots of output.]

I would expect that that data is still being written to memory/swap even if the window isn't visible, which would leave me to believe the slowness would persist if that were the cause.

Also I can't imagine the memory management has changed drastically since the last major release (of course, could be wrong), and this behavior did not exist in the last version. This is unique to 3.

Hard to say what's going on just from the sample. It spent 861 of 2523 samples in objc_msgSend, which is insane (it normally completes in 12 assembly instructions). Either it's attributed incorrectly or the process didn't get timeslices. A lot has changed since the last release, so it's hard to say exactly what's going on here. Ideally I'd profile this in Instruments’ CPU profiler with the hope of getting more accurate info, and also keep an eye on activity monitor to see if there's a ton of disk IO when it's being slow.

Have you been able to recreate it on your end by chance?

Made the issue visible