v3 is very slow and unresponsive

Thanks for filing an issue! Please answer the questions below so I can help you.

• iTerm2 version: I was on 3.0.12, I recently tried downgrading to 3.0.5 as suggested in https://gitlab.com/gnachman/iterm2/issues/5154
• OS version: 10.12.1
• Attach com.googlecode.iterm2.plist here com.googlecode.iterm2.plist
• Attach a debug log, if possible. n/a
• Are you reporting a performance issue or a hang? Sample_of_iTerm2.txt
• Are you reporting a crash? Please attach the crash log. n/a

Detailed steps to reproduce the problem:

1. anything cursor related... typing, deleting, moving around in the terminal
2. massive responsiveness regression from how I remember iTerm2 being in the past

What happened: It's just painful to use now. Have been putting up with it for a few weeks or months, can't say when exactly. But it's like that all the time pretty much now.

Actually, more specifically it's editing - typing and deleting - that is slow. Moving around the current line with the cursor is ok. And using up arrow to go through history can also be slow. Maybe it's something around rendering new text.

You have the misfortune of displaying some text that takes the slowest possible rendering path. This can happen with certain fonts or if your text contains a lot of traditional Chinese characters, emoji, or other text that uses Unicode outside the basic multilingual plane. Does changing the font help? Is the nightly build any faster for you?

Hi, that's unfortunate. I've been using https://github.com/banga/powerline-shell for many years, along with a matching font, and I guess I have unicode in my command prompt.

Is it possible to download a 2.x version of iTerm2 from before the rendering path was changed to this new slow one? I was very happy with it for many years.

Somehow I missed that you were on 3.0.12, so that answer doesn't apply to your situation. Sorry about that! I have a few ideas about what might be going on:

• I recently discovered a performance issue when the cursor shape changes or its visibility changes. This is especially problematic in tmux. I applied the change to 3.1 but it hasn't made it into 3.0.x yet. Can you please test this build and see if it helps? http://iterm2.com/adhocbuilds/iTerm2-3_0_20161208_101604-adhoc.zip
• Drawing has been rewritten in the nightly build, and it may help your situation, or perhaps not (the key change is the frame rate can be reduced when drawing becomes a bottleneck). Please try https://iterm2.com/nightly/latest and let me know if it's faster for you.

Since what you describe is slow editing, it sounds like there's extra latency between pressing a key and a redraw happening. The attached sample might not be representative of the problem you report. A debug log would be helpful to see what's going on. Turn on debug logging, do some editing that feels slow, and turn it back off, then attach the log here. Full instructions on creating a debug log are at https://iterm2.com/debuglog

Thanks!

mentioned in issue #794

Slow performance was bugging me too, so I just ran a few benchmarks with /bin/ls -R on $/linux/arch and came up with this (cf. #794 which is way older but which I found first):

| App      | background   | user | system | total |
|----------+--------------+------+--------+-------|
| iTerm    | none         | 0.11 |   0.20 |  0.63 |
|          | image        | 0.11 |   0.18 |  3.78 |
|          | blur         | 0.12 |   0.18 |  3.61 |
|          | image + blur | 0.11 |   0.15 |  5.61 |
|----------+--------------+------+--------+-------|
| Terminal | none         | 0.07 |   0.10 |  0.21 |
|          | image        | 0.10 |   0.13 |  0.27 |
|          | blur         | 0.10 |   0.13 |  0.27 |
|          | image + blur | 0.07 |   0.11 |  0.23 |
|----------+--------------+------+--------+-------|
| iTerm    | none         | 0.10 |   0.17 |  0.40 |
| nightly  | image        | 0.10 |   0.16 |  1.33 |
|          | blur         | 0.12 |   0.19 |  1.54 |
|          | image + blur | 0.11 |   0.17 |  1.73 |

Hi,

I am wondering if it is scrollback-related

I have already turned off infinite scrollback but I will have iTerm2 open for days or weeks at a time. I just had to reboot the laptop a couple of times recently and I noticed both times that iTerm is zippy again once it's opened freshly

@anentropic Infinite scrollback could use up all your memory, so you might not want to do that.

Terminal has a much flatter view hierarchy than iTerm2, in part because it does not use a scroll view. Ditching NSScrollView could buy me a big performance win. I guess AppKit is in worse shape than I'd imagined…

changed milestone to %Review for next version

I can confirm that with Nightly, FPS drops way below 30 FPS when editing/scrolling etc in (n)vim. v3.0.5 resolves the issue. I'm looking forward to 3.2 because of better sRGB colors and ligatures (if they don't kill the performance).

BTW with the nightly build, I've tried disabling all the experimental FPS adapting options, which didn't help.

@anilanar Are you using a font with ligatures? If you can attach your $HOME/Library/Preferences/com.googlecode.iterm2.plist file I'll see what's going on with your config.

@gnachman Restarting iTerm2 after turning off ligatures and setting adaptive framerate to false resolved my issue with nightly. If at least one of them is turned on, I experience degraded FPS.

Perhaps I can make adaptive framerate work if I increase the throughput threshold but I'm not sure what number makes sense. When scrolling in vim, iTerm2 CPU usage can exceed 50% but never seen it hit 100%.

I'm wondering though, what makes OSX native terminal super fast?

Here is my current plist just in case:

com.googlecode.iterm2.plist

I wonder if your system is faster than the one I tested on. The adaptive framerate feature probably needs tweaking. Try bumping up the adaptive framerate throughput threshold and see if it helps.

You might not be drawing-limited. The key place where adaptive framerate makes a difference is when you print a big file (like if you cat a file with 10,000 lines). It's better to draw slower and spend more CPU on crunching the input since only the last screen of output will be legible. On a macbook pro with a 4k display attached (which is what I use at work) the graphics hardware is so overburdened that there'd be almost no time left to do anything but draw.

What's your hardware (machine and display)?

As far as I can tell the OSX native terminal uses the same miserably slow drawing calls as I do but they're clever about adjusting the framerate (it goes from 10 to 30 FPS).

I am on a Macbook Air i7 2.0ghz 8GB connected to a 1920x1080 display

That shouldn't be very fast, so maybe my hypothesis is wrong. If you increase the adaptive framerate threshold do you see an improvement? If not I'll give you a build with some logging to see just what's going on.