Scrolling in less/more is slow

Comment 1 by cesp... on April 12, 2011 01:01

More info: the problem is also a lot worse when the terminal is big. If I make the terminal really tiny the problem isn't as bad, and if I fullscreen then it gets comically bad. (I work on a 30-incher, so fullscreen = 2560x1600 px.)

In case it's relevant, I'm using my laptop screen and the external monitor.

Comment 2 by cesp... on April 12, 2011 01:08

One more update (sorry to keep spamming this): I compared to Terminal.app and discovered that it suffers from the same kind of performance degradation but to a much lesser degree. I only start to notice any kind of slowdown at all when I make my Terminal window really big (most of the screen). To try and keep the comparison fair, I have the same font in both and transparency enabled in both.

Comment 3 by gnach... on April 12, 2011 02:32

Make sure you don't have adjustable stroke width enabled.

Comment 4 by cesp... on April 12, 2011 16:02

Adjustable font width seems to have been removed from the build I'm running (4/10 nightly).

Comment 5 by gnach... on April 29, 2011 15:56

Hm, do you have a background image?

Comment 6 by troy.bollin... on May 15, 2011 00:48

I see the same kind of problem when editing a file with vim and holding down 'j' to scroll down through the file. It's especially noticeable when using 'j' to scroll through a vim help screen (:help). I'm using iTerm2 build 0.20.20110413 on OSX 10.6.7 macbook air with an 80x24 term, opaque transparency, no blur, no background image, hidden scrollbar, and anti-aliased Monaco 10pt font.

Comment 7 by geor...@google.com on May 15, 2011 20:29

How many rows/columns does your session have when less exhibits this problem? You can get it with stty -a.

Terminal is definitely faster in this case, but I can't see any trickery that they're doing from the activity monitor sample. Both of us spend all our time drawing text AFAICT.

There's an easy but small win by keeping a per-line digest of the dirty flags (a count of the two types of dirty flags)

Comment 8 by geor...@google.com on May 15, 2011 20:34

Another thought: keep a fingerprint of each line onscreen (fp = hash(screen_char_t[i] for i=0...WIDTH-1)) . Then we can quickly detect when a line is moved from one part of the screen to another and just copy the pixels. Can't do it if there's a background image, textview size has changed, or there's been any change to the background image. This would greatly speed up scrolling on a gigantic screen. Each line would have a fingerprint computed in updateDirtyRects and invalidated when any part of it changes, then recomputed lazily.

Comment 9 by troy.bollin... on May 15, 2011 22:22

$ stty -a
speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ; dsusp = ^Y; eof = ^D; eol = ;
eol2 = ; erase = ^?; intr = ^C; kill = ^U;
lnext = ; min = 1; quit = ^; reprint = ^R; start = ^Q;
status = ; stop = ^S; susp = ^Z; time = 0; werase = ^W;

Comment 10 by geor...@google.com on May 15, 2011 23:08

At 24x80 is it slower than Terminal?

Comment 11 by troy.bollin... on May 15, 2011 23:43

They are both about the same speed, but iTerm2 is significantly more jerky when scrolling down a line at a time. Terminal scrolls smoothly for the first second or two and then jerks intermittently, while iTerm2 is continuously jerky.

Comment 12 by ism...@namtrac.org on May 19, 2011 18:34

A good testcase is doing ls ///* (tried with zsh);

with iTerm2 Build 0.20.20110512:

ls --color ///* 0.56s user 0.32s system 3% cpu 24.316 total

with Terminal.app from OSX 10.6.7:

ls --color ///* 0.54s user 0.28s system 64% cpu 1.266 total

so its magnitudes slower in iTerm2 which also happens when you compile something on iTerm2, its really slow to update the whole screen.

Not using any background image btw.

Comment 13 by geor...@google.com on May 19, 2011 18:45

I found that 5/12 is substantially slower than Beta 1. I believe I know why, but for benchmarks stick to B1 for now.

Comment 14 by ism...@namtrac.org on May 19, 2011 18:49

Beta 1 is way better:

ls --color ///* 0.56s user 0.39s system 16% cpu 5.866 total

but still somewhat slower than Terminal.app

Comment 15 by gnach... on May 20, 2011 04:59

I fixed the slowness introduced after b1. There's still an issue when in an alternate screen (e.g., less).

Comment 16 by dustin.bre... on May 26, 2011 15:31

Sweet -- your latest version () seems to have kicked the slowness. All test results below with terminal window size maxed on my display at 235x60.

In version 0.20.20110526, test results:
RESULTS BLUR ENABLED:
$ time
real 0m0.053s
user 0m0.001s
sys 0m0.006s

RESULTS BLUR DISABLED:
real 0m0.054s
user 0m0.001s
sys 0m0.005s

In version 0.20.20110512, test results:

RESULTS BLUR ENABLED:
$ time cat garbage.txt
real 0m9.359s
user 0m0.001s
sys 0m0.007s

BLUR DISABLED:
$ time cat garbage.txt
real 0m7.537s
user 0m0.001s
sys 0m0.007s

Using ITERM 1:
$ time cat garbage.txt
real 0m0.317s
user 0m0.001s
sys 0m0.005s

My test script:
$ cat garbage.pl
#!/opt/local/bin/perl

while (

There was an error rendering this math block. KaTeX parse error: Expected &amp;#39;}&amp;#39;, got &amp;#39;EOF&amp;#39; at end of input: \dots00) { while (

j++ < 230) {
print "x";
}
print "\n";
$j = 0;
}

Generate "garbage.txt" file:
$ perl ./garbage.pl > garbage.txt

Comment 17 by troy.bollin... on June 03, 2011 13:55

Just now trying beta2... the jerkiness I saw in vim is completely gone! Thanks for fixing this.

Comment 18 by cesp... on June 03, 2011 21:23

I'm trying beta 2 and the jerkiness seems greatly improved -- in fact, in my subjective testing it feels pretty much on par or better than Terminal.app.

Thanks a bunch for working on this :)

Comment 19 by ...@wincent.com on April 02, 2014 15:28

(Reviving an old ticket...)

With the current release (1.0.0.20140112) I'm still seeing a pretty big delta between Terminal.app and iTerm 2 performance.

I modified the (Reviving an old ticket...)

With the current release (1.0.0.20140112) I'm still seeing a pretty big delta between Terminal.app and iTerm 2 performance.

I modified the garbage.pl(Reviving an old ticket...)

With the current release (1.0.0.20140112) I'm still seeing a pretty big delta between Terminal.app and iTerm 2 performance.

I modified the `garbage.pl script from comment 16 above to produce a 1,000,000 line file and ran some tests. Out of the box, Terminal.app can dump this file to the screen in 6-7 seconds (this is with the window at maximum size on my 13" laptop display).

iTerm 2 was taking about 4 times as long (21-26 seconds).

I already have the "expensive" features (background transparency, blur, images) turned off, so I went looking for other possible candidates:

- disabled the scrollbar (no effect)
- turned off unlimited scrollback; setting scrollback to 0 brought the time down to 12-13 secs (about twice as slow as Terminal.app)

Any other ideas for settings that could be tweaked to improve performance? The feature set and stability are great now; performance is really the only department in which iTerm 2 isn't winning.

Comment 20 by gnach... on April 02, 2014 16:50

win, please try the nightly build. It is substantially faster*.

On ASCII text.

Comment 21 by ...@wincent.com on April 28, 2014 04:56

Just tried the latest release. The gap does seem smaller now, with Terminal.app only 1.67x faster than iTerm.

iTerm took 10.491 seconds to output a million lines, and Terminal.app took 6.284 seconds for the same task.

(For both apps I took the best of three runs).

Comment 22 by ...@wincent.com on August 08, 2014 17:11

Just wanted to chime in again. I still occasionally see big slow-downs in iTerm 2. The current instance I have has been running for about 2 days and was getting painfully slow (eg. redrawing during scrolling in Vim taking several hundred milliseconds per update). I opened Terminal to compare, connected to the same remote host, same tmux session, and scrolling was buttery smooth. I quite iTerm 2 and re-opened it, and scrolling was fast again.

I have "Scrollback Lines" set to 0, and "Unlimited scrollback" is unchecked, so it's not related that but it is somehow related to the age of the session.

Currently on Build 1.0.0.20140629 (worth moving to 2.0?).

Comment 23 by gnach... on August 11, 2014 05:53

The nightly build has some significant performance improvements over 2.0; I wonder if you see the same thing there? iterm2.com/nightly/latest

Comment 24 by ...@wincent.com on August 11, 2014 18:32

It seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by It seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by timeIt seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by `time:

Terminal.app
- cat 1m lines: 6.623s (best of 3 runs)

1.0.0.20140629
- cat 1m lines: 16.715s (best of 3 runs)

2.0
- cat 1m lines: 17.702 (best of 3 runs)

2.9.20140811-nightly
- cat 1m lines: 11.219s (best of 3 runs)

But running the same test inside tmux reveals some warts:

- Terminal.app: 62.02s
- 1.0.0.20140629: 47.175s
- 2.9.20140811-nightly: 58.011s

That last figure is highly suspicious however; it appears that the It seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by time:

Terminal.app
- cat 1m lines: 6.623s (best of 3 runs)

1.0.0.20140629
- cat 1m lines: 16.715s (best of 3 runs)

2.0
- cat 1m lines: 17.702 (best of 3 runs)

2.9.20140811-nightly
- cat 1m lines: 11.219s (best of 3 runs)

But running the same test inside tmux reveals some warts:

- Terminal.app: 62.02s
- 1.0.0.20140629: 47.175s
- 2.9.20140811-nightly: 58.011s

That last figure is highly suspicious however; it appears that the timeIt seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by time:

Terminal.app
- cat 1m lines: 6.623s (best of 3 runs)

1.0.0.20140629
- cat 1m lines: 16.715s (best of 3 runs)

2.0
- cat 1m lines: 17.702 (best of 3 runs)

2.9.20140811-nightly
- cat 1m lines: 11.219s (best of 3 runs)

But running the same test inside tmux reveals some warts:

- Terminal.app: 62.02s
- 1.0.0.20140629: 47.175s
- 2.9.20140811-nightly: 58.011s

That last figure is highly suspicious however; it appears that the `time command exits long before tmux has finished repainting the screen. While the time for 1.0.0 felt close to right, the 2.9 time was an order of magnitude off (ie. it actually took close to 10 minutes before control was returned to the terminal).

I repeated this with a smaller file (10k lines). It seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by time:

Terminal.app
- cat 1m lines: 6.623s (best of 3 runs)

1.0.0.20140629
- cat 1m lines: 16.715s (best of 3 runs)

2.0
- cat 1m lines: 17.702 (best of 3 runs)

2.9.20140811-nightly
- cat 1m lines: 11.219s (best of 3 runs)

But running the same test inside tmux reveals some warts:

- Terminal.app: 62.02s
- 1.0.0.20140629: 47.175s
- 2.9.20140811-nightly: 58.011s

That last figure is highly suspicious however; it appears that the time command exits long before tmux has finished repainting the screen. While the time for 1.0.0 felt close to right, the 2.9 time was an order of magnitude off (ie. it actually took close to 10 minutes before control was returned to the terminal).

I repeated this with a smaller file (10k lines). timeIt seems the nightly is a bit of a mixed bag; raw output seems to be faster, as measured by time:

Terminal.app
- cat 1m lines: 6.623s (best of 3 runs)

1.0.0.20140629
- cat 1m lines: 16.715s (best of 3 runs)

2.0
- cat 1m lines: 17.702 (best of 3 runs)

2.9.20140811-nightly
- cat 1m lines: 11.219s (best of 3 runs)

But running the same test inside tmux reveals some warts:

- Terminal.app: 62.02s
- 1.0.0.20140629: 47.175s
- 2.9.20140811-nightly: 58.011s

That last figure is highly suspicious however; it appears that the time command exits long before tmux has finished repainting the screen. While the time for 1.0.0 felt close to right, the 2.9 time was an order of magnitude off (ie. it actually took close to 10 minutes before control was returned to the terminal).

I repeated this with a smaller file (10k lines). `time reported a total duration of 1.5s, but the time measured by wall clock was actually 102 seconds... This is with tmux 1.9a installed via homebrew. I tested 2.0 and the reported duration was around 1.3s, and the wall clock was very close to the same (1-2 seconds), so this seems like a regression in the nightly.

I use tmux basically full-time, so this is a blocker for me.

Comment 25 by gnach... on August 12, 2014 03:52

I'd like to reproduce what you're seeing in tmux. I tried doing this:

Run tmux 1.9a on Mac OS 10.9. Note this is not the tmux integration with the -CC argument, just plain tmux with all default config settings.
Print 1 million lines of random ascii output, where each line is a random length (distributed uniformly) between 0 and 100 characters in length.

But the wall clock time was reasonable (10-20 seconds, certainly not 10 minutes).

If you're using a very old machine with a single core, that could possibly explain some of this, but even so, what you're seeing is crazy. Could you do this:

Start a new shell, not in tmux yet
Do Shell>Log>Start
launch tmux
cat the 10k line file that took 102 seconds of wall time
Do Shell>log>stop
Exit tmux
Verify that printing the log file to the screen takes about 100 seconds.
Attach the log file to this issue
Also attach your ~/Library/Preferences/com.googlecode.iterm2.plist file to this issue

Thanks for your help in diagnosing this issue.

Comment 26 by ...@wincent.com on August 12, 2014 14:51

Attaching the log and the plist file.

I obtained the log using the steps you specified. Same as yesterday, cating the file took almost two minutes, even though Attaching the log and the plist file.

I obtained the log using the steps you specified. Same as yesterday, cating the file took almost two minutes, even though timeAttaching the log and the plist file.

I obtained the log using the steps you specified. Same as yesterday, cating the file took almost two minutes, even though `time claims it only took a couple of seconds. Outside of tmux, the same file cats basically instantly.

Also attaching the Perl script I used to generate the test file. It makes a file 10k lines long, 360 characters per line (ie. wide enough to almost fill the entire terminal when it is at full size on my external display).

All of this is on a mid-2013 MacBook Air 1.7 GHz Intel Core i7 (4 cores) with 8 GB 1600 MHz DDR3 running OS X 10.9.4 and tmux 1.9a from homebrew (updated yesterday) without the iTerm integration. This machine has Intel HD Graphics 5000 integrated graphics, and is driving a 2560x1440 Apple Thunderbolt Display, which is where I ran these tests with the iTerm window maximized to about 364 x 81 chars.

To sanity check, I retested with 2.0 (not the nightly) and it doesn't exhibit this problem.

In case it matters, you can see my .tmux.conf here:

https://github.com/wincent/wincent/blob/master/.tmux.conf

Yesteraday I was originally suspicious that my c0-change-trigger and c0-change-interval settings might be involved, so I commented those out and closed all tmux sessions and re-ran the tests. The behavior is the same.

com.googlecode.iterm2.plist

iterm-log

garbage.pl

Comment 27 by gnach... on September 16, 2014 22:34

@win, does turning on prefs>profiles>terminal>"save lines to scrollback in alternate screen" produce a dramatic speedup for you?

Comment 28 by gnach... on September 16, 2014 22:41

The slowness in tmux was (hopefully) fixed in fc6b7aee

Comment 29 by ...@wincent.com on September 17, 2014 06:41

Yep, it does indeed look like fc6b7aee fixed it. Good find.

Here are some unscientific results (one run only, 1m lines, laptop internal screen only):

iTerm 1:

- outside of tmux: 12.8s
- with alternate screen saving on: 12.046s
- inside tmux: 1:20.60

Bad nightly I tested in my previous comment (2.9.20140811-nightly):

- inside tmux with alternate screen saving on: 58.691s (wallclock roughly matches)
- inside tmux: [doesn't finish]

Build of current HEAD of master (caa75e9e):

- outside of tmux: 9.834s
- inside tmux: 1:16.09 (roughly matches wallclock time)
- inside tmux with alternate screen saving on: 1:18.34

Thanks for the fix!

Comment 30 by abazh... on September 19, 2014 17:43

Scrolling a file using Scrolling a file using lessScrolling a file using `less command is very slow when a terminal background image is set.

Tested with: Build 2.9.20140919-nightly

Comment 31 by File... on March 24, 2015 14:02

Scrolling still feels laggy when a background image is set. The problem doesn't occur when the iTerm window is small. In Terminal.app everything works smooth (even if the window is full screen).

Build 2.0.0.20141103

Comment 32 by gnach... on April 15, 2015 02:58

@FileNox, try the nightly build. Background images should significantly zippier.

Milestone changed to Future Release

This issue still seems to persist (see also #5369). I just conducted some measurements with time /bin/ls -R on ~/linux/arch and came up with this:

| 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 |

Edit: Add results for nightly build.

mentioned in issue #5369

The nightly build got some improvements in the 12/22 build (unless your font uses ligatures, and then you're hosed).

Just tried the 12/25 nightly, but couldn't detect any speed improvement over the build I was previously using (Build 3.0.20161213-nightly):

3.0.20161213, outside tmux

0.00s user 0.81s system 11% cpu 6.919 total

3.0.20161213, inside tmux

0.00s user 1.22s system 1% cpu 1:23.94 total

3.0.20161225, outside tmux

0.00s user 0.80s system 11% cpu 6.899 total

3.0.20161225, inside tmux

0.00s user 1.29s system 1% cpu 1:24.73 total

(1 million lines, best of three runs for each.).

I'm using Adobe Source Code Pro Light, so I don't think ligatures are at issue here.

FWIW, there was a regression in tmux that I reported here which highlighted that rendering performance can still be a problem at large window sizes. Quoting this comment:

It looks like your terminal just can't keep up with the volume of data once we start redrawing, so the amount of data that tmux has buffered gets bigger and bigger.
1491313185.674857 /dev/ttys011: wrote 1024 bytes (of 74365)
...
1491313192.568442 /dev/ttys011: wrote 1024 bytes (of 38423119)

That issue has a mitigation that causes tmux to slow down updates when it detects that the terminal isn't keeping up. With the mitigation in place, tmux + less is usable in large windows in iTerm (specifically, I am using Build 3.1.20170331-nightly with no ligatures or anything fancy), but Terminal.app is noticeably smoother still. The tmux maintainer can't repro the issue, so whatever (presumably Linux) terminal he is using is fast enough for this not to manifest inside it.

@wincent I can reproduce this slowness when using the left pane. The right pane is nice and fast for me. Looking into it.

I just wanted to leave this here... for anyone who cares.

The issue is way worse in iterm than the osx built-in terminal app...

There was a lot of discussion as to whether this is an issue in tmux, osx, etc... in the tmux issue from @wincent above...

I think the issue is definitely iTerm though, as is clearly evident below:

Here's proof: https://www.youtube.com/watch?v=4CJk52qUtqE

Input lag differences are not as bad as output... as seen here: https://www.youtube.com/watch?v=GsQiH4nN05M

I'm inputting to iterm2 on the left, and the terminal on the right is much faster to react than iterm.

@linuxinit In your first video, were iTerm2 and Terminal doing the same thing? I barely saw the Terminal window change. What kind of machine are you on and what resolution display are you using, if it's external?

hi @gnachman

here's what you're seeing:

both terminals are attached to the same tmux session.

iterm outputs WAY slower than terminal. when you say you barely saw the terminal window change, that's because it didn't lag and buffer and choke on the output. it's done rendering before iterm even begins to choke.

it's an output buffering/drawing issue with iterm.

in the second video, i am inputting via iterm, and you can see tmux react in terminal way way before iterm even registers the input.

further proof of this is via the log outputs, it has a timestamp. you can see how fast terminal outputs, where-as iterm is lagging horribly

as for the machine... it's a macbook pro running an external 4k display (samsung U28D590D) via mini display port (over thunderbolt) via another thunderbolt device doing daisy chain. i don't think the display is the issue, however... as you can see both terminals running on the same display, side-by-side, in real time, so i'm not really sure how the display is really relevant.

it should be running at 4k native resolution though, so maybe iterm is choking badly on the resolution, you mean, where-as terminal does not? hmm...

it seems to be some kind of issue with output buffering, you can see it trying to redraw everything for each line that is outputted, where-as terminal does it MUCH faster, not sure if it's just skipping draws or what.

and for what it's worth, i'm running latest iterm beta build and latest tmux stable release.

Thanks for the detailed feedback. It's good to know this was an external 4K display. I wonder if you could do one more thing:

Close all iTerm2 windows
Turn on Prefs > Advanced > Log stats about text drawing performance to console
Open Console.app and enter a search for iterm2 in the search field in the top-right of the window
Create an iTerm2 window and reproduce the slow scrolling for 15 seconds
Copy-paste the log messages that were written to Console.app during the slow scrolling. The should look something like this:

-- Precise Timers --
      Total drawRect: µ=6.917ms σ=1.307ms (95% CI ≅ 5.610ms–8.225ms) 𝚺=518.81ms N=75 avg. events=1
   Construct BG runs: µ=0.341ms σ=0.028ms (95% CI ≅ 0.314ms–0.369ms) 𝚺=25.60ms N=75 avg. events=25
             Draw BG: µ=0.982ms σ=0.513ms (95% CI ≅ 0.469ms–1.495ms) 𝚺=73.62ms N=75 avg. events=1
        Construction: µ=2.716ms σ=0.800ms (95% CI ≅ 1.916ms–3.516ms) 𝚺=203.72ms N=75 avg. events=26
  Build attr strings: µ=0.815ms σ=0.153ms (95% CI ≅ 0.661ms–0.968ms) 𝚺=61.09ms N=75 avg. events=197
       Compute Attrs: µ=0.368ms σ=0.061ms (95% CI ≅ 0.307ms–0.429ms) 𝚺=27.57ms N=75 avg. events=1117
             Segment: µ=1.042ms σ=0.199ms (95% CI ≅ 0.844ms–1.241ms) 𝚺=78.18ms N=75 avg. events=216
            Advances: µ=0.040ms σ=0.005ms (95% CI ≅ 0.035ms–0.046ms) 𝚺=3.01ms N=75 avg. events=1098
       Combine Attrs: µ=0.440ms σ=0.621ms (95% CI ≅ 0.000ms–1.061ms) 𝚺=33.01ms N=75 avg. events=216
      Update Builder: µ=0.370ms σ=0.071ms (95% CI ≅ 0.298ms–0.441ms) 𝚺=27.71ms N=75 avg. events=1098
             Drawing: µ=2.691ms σ=0.493ms (95% CI ≅ 2.198ms–3.184ms) 𝚺=201.82ms N=75 avg. events=26
       Between calls: µ=59.780ms σ=19.378ms (95% CI ≅ 40.402ms–79.158ms) 𝚺=4483.53ms N=75 avg. events=1

This will help me to make sure I'm concentrating on the right part of the problem that you are experiencing.

I have made a few changes that will improve performance for most users, at the expense of annoying a minority.

The cause of poor performance is ligature support. It forces the use of Core Text, which is extremely slow compared to Quartz. Apple seems to mitigate this by not using NSScrollView and having a very flat view hierarchy. At least, that's all I can figure.

The default fonts that ship with the system do not have ligatures and so I have disabled the ligature code path for them.

The riskier change (in terms of people filing lots of issues) is that ligature support is now off by default. If you were using ligatures, you'll need to re-enable them in Prefs > Profiles > Text.

On my system, disabling ligatures improves drawing performance by a factor of almost 5x.

For what its worth, I have similar issues in the beta, Build 3.1.beta.5 (i've had them for a while, an they were gone for quite some time, but seem to have returned). I've added the output of my iterm2 logs:

default	16:44:32.778909 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=72.144ms σ=6.198ms (95% CI ≅ 65.947ms–78.342ms) 𝚺=505.01ms N=7 avg. events=1
   Construct BG runs: µ=0.656ms σ=0.056ms (95% CI ≅ 0.600ms–0.712ms) 𝚺=4.59ms N=7 avg. events=91
             Draw BG: µ=2.168ms σ=0.941ms (95% CI ≅ 1.226ms–3.109ms) 𝚺=15.18ms N=7 avg. events=1
        Construction: µ=27.525ms σ=0.608ms (95% CI ≅ 26.917ms–28.133ms) 𝚺=192.67ms N=7 avg. events=555
  Build attr strings: µ=9.206ms σ=0.245ms (95% CI ≅ 8.961ms–9.452ms) 𝚺=64.44ms N=7 avg. events=4002
       Compute Attrs: µ=3.172ms σ=0.085ms (95% CI ≅ 3.087ms–3.257ms) 𝚺=22.20ms N=7 avg. events=30961
             Segment: µ=9.202ms σ=0.244ms (95% CI ≅ 8.958ms–9.446ms) 𝚺=64.41ms N=7 avg. events=4434
            Advances: µ=0.731ms σ=0.015ms (95% CI ≅ 0.716ms–0.746ms) 𝚺=5.12ms N=7 avg. events=30927
       Combine Attrs: µ=4.325ms σ=0.083ms (95% CI ≅ 4.241ms–4.408ms) 𝚺=30.27ms N=7 avg. events=4434
      Update B
default	16:44:38.780012 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=76.947ms σ=4.911ms (95% CI ≅ 72.036ms–81.857ms) 𝚺=384.73ms N=5 avg. events=1
   Construct BG runs: µ=0.750ms σ=0.105ms (95% CI ≅ 0.645ms–0.855ms) 𝚺=3.75ms N=5 avg. events=91
             Draw BG: µ=2.960ms σ=0.900ms (95% CI ≅ 2.059ms–3.860ms) 𝚺=14.80ms N=5 avg. events=1
        Construction: µ=28.154ms σ=0.535ms (95% CI ≅ 27.619ms–28.688ms) 𝚺=140.77ms N=5 avg. events=556
  Build attr strings: µ=9.407ms σ=0.227ms (95% CI ≅ 9.179ms–9.634ms) 𝚺=47.03ms N=5 avg. events=4011
       Compute Attrs: µ=3.207ms σ=0.083ms (95% CI ≅ 3.124ms–3.291ms) 𝚺=16.04ms N=5 avg. events=31100
             Segment: µ=9.410ms σ=0.210ms (95% CI ≅ 9.201ms–9.620ms) 𝚺=47.05ms N=5 avg. events=4509
            Advances: µ=0.751ms σ=0.022ms (95% CI ≅ 0.729ms–0.773ms) 𝚺=3.76ms N=5 avg. events=31065
       Combine Attrs: µ=4.422ms σ=0.129ms (95% CI ≅ 4.293ms–4.550ms) 𝚺=22.11ms N=5 avg. events=4509
      Update B
default	16:44:44.048202 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=71.685ms σ=5.175ms (95% CI ≅ 66.510ms–76.860ms) 𝚺=215.06ms N=3 avg. events=1
   Construct BG runs: µ=0.677ms σ=0.061ms (95% CI ≅ 0.616ms–0.738ms) 𝚺=2.03ms N=3 avg. events=91
             Draw BG: µ=1.999ms σ=0.955ms (95% CI ≅ 1.045ms–2.954ms) 𝚺=6.00ms N=3 avg. events=1
        Construction: µ=27.909ms σ=0.440ms (95% CI ≅ 27.469ms–28.350ms) 𝚺=83.73ms N=3 avg. events=555
  Build attr strings: µ=9.351ms σ=0.102ms (95% CI ≅ 9.249ms–9.453ms) 𝚺=28.05ms N=3 avg. events=4006
       Compute Attrs: µ=3.181ms σ=0.050ms (95% CI ≅ 3.131ms–3.231ms) 𝚺=9.54ms N=3 avg. events=31019
             Segment: µ=9.359ms σ=0.111ms (95% CI ≅ 9.248ms–9.471ms) 𝚺=28.08ms N=3 avg. events=4439
            Advances: µ=0.749ms σ=0.003ms (95% CI ≅ 0.747ms–0.752ms) 𝚺=2.25ms N=3 avg. events=30985
       Combine Attrs: µ=4.389ms σ=0.120ms (95% CI ≅ 4.269ms–4.509ms) 𝚺=13.17ms N=3 avg. events=4439
      Update Buil
default	16:44:49.075016 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=34.945ms σ=21.344ms (95% CI ≅ 13.601ms–56.288ms) 𝚺=2481.06ms N=71 avg. events=1
   Construct BG runs: µ=0.338ms σ=0.206ms (95% CI ≅ 0.132ms–0.544ms) 𝚺=24.00ms N=71 avg. events=47
             Draw BG: µ=0.836ms σ=0.614ms (95% CI ≅ 0.222ms–1.450ms) 𝚺=59.36ms N=71 avg. events=1
        Construction: µ=14.574ms σ=8.192ms (95% CI ≅ 6.382ms–22.767ms) 𝚺=1034.77ms N=71 avg. events=270
  Build attr strings: µ=4.760ms σ=2.754ms (95% CI ≅ 2.006ms–7.514ms) 𝚺=337.97ms N=71 avg. events=2118
       Compute Attrs: µ=1.600ms σ=0.956ms (95% CI ≅ 0.644ms–2.555ms) 𝚺=113.57ms N=71 avg. events=16189
             Segment: µ=4.848ms σ=2.735ms (95% CI ≅ 2.114ms–7.583ms) 𝚺=344.24ms N=71 avg. events=2289
            Advances: µ=0.382ms σ=0.224ms (95% CI ≅ 0.157ms–0.606ms) 𝚺=27.09ms N=71 avg. events=16170
       Combine Attrs: µ=2.234ms σ=1.309ms (95% CI ≅ 0.925ms–3.543ms) 𝚺=158.60ms N=71 avg. events=22
default	16:44:54.084217 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=48.472ms σ=31.257ms (95% CI ≅ 17.214ms–79.729ms) 𝚺=2908.29ms N=60 avg. events=1
   Construct BG runs: µ=0.453ms σ=0.279ms (95% CI ≅ 0.174ms–0.732ms) 𝚺=27.18ms N=60 avg. events=61
             Draw BG: µ=1.413ms σ=0.924ms (95% CI ≅ 0.490ms–2.337ms) 𝚺=84.81ms N=60 avg. events=1
        Construction: µ=18.514ms σ=11.737ms (95% CI ≅ 6.777ms–30.250ms) 𝚺=1110.82ms N=60 avg. events=375
  Build attr strings: µ=6.127ms σ=3.897ms (95% CI ≅ 2.230ms–10.023ms) 𝚺=367.59ms N=60 avg. events=2615
       Compute Attrs: µ=2.123ms σ=1.363ms (95% CI ≅ 0.761ms–3.486ms) 𝚺=127.39ms N=60 avg. events=20934
             Segment: µ=6.111ms σ=3.875ms (95% CI ≅ 2.236ms–9.986ms) 𝚺=366.67ms N=60 avg. events=2907
            Advances: µ=0.495ms σ=0.318ms (95% CI ≅ 0.176ms–0.813ms) 𝚺=29.67ms N=60 avg. events=20910
       Combine Attrs: µ=2.897ms σ=1.855ms (95% CI ≅ 1.042ms–4.752ms) 𝚺=173.83ms N=60 avg. events=
default	16:44:59.106633 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=44.190ms σ=30.679ms (95% CI ≅ 13.511ms–74.868ms) 𝚺=2960.70ms N=67 avg. events=1
   Construct BG runs: µ=0.417ms σ=0.286ms (95% CI ≅ 0.131ms–0.703ms) 𝚺=27.93ms N=67 avg. events=57
             Draw BG: µ=1.290ms σ=0.928ms (95% CI ≅ 0.362ms–2.217ms) 𝚺=86.40ms N=67 avg. events=1
        Construction: µ=17.223ms σ=11.556ms (95% CI ≅ 5.667ms–28.778ms) 𝚺=1153.91ms N=67 avg. events=347
  Build attr strings: µ=5.665ms σ=3.862ms (95% CI ≅ 1.802ms–9.527ms) 𝚺=379.52ms N=67 avg. events=2425
       Compute Attrs: µ=1.958ms σ=1.345ms (95% CI ≅ 0.614ms–3.303ms) 𝚺=131.20ms N=67 avg. events=19423
             Segment: µ=5.663ms σ=3.848ms (95% CI ≅ 1.815ms–9.511ms) 𝚺=379.41ms N=67 avg. events=2694
            Advances: µ=0.460ms σ=0.314ms (95% CI ≅ 0.145ms–0.774ms) 𝚺=30.79ms N=67 avg. events=19401
       Combine Attrs: µ=2.681ms σ=1.839ms (95% CI ≅ 0.843ms–4.520ms) 𝚺=179.66ms N=67 avg. events=2
default	16:45:04.127296 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=40.628ms σ=21.640ms (95% CI ≅ 18.988ms–62.267ms) 𝚺=3534.59ms N=87 avg. events=1
   Construct BG runs: µ=0.403ms σ=0.213ms (95% CI ≅ 0.190ms–0.616ms) 𝚺=35.08ms N=87 avg. events=56
             Draw BG: µ=0.934ms σ=0.597ms (95% CI ≅ 0.337ms–1.531ms) 𝚺=81.26ms N=87 avg. events=1
        Construction: µ=16.979ms σ=8.523ms (95% CI ≅ 8.456ms–25.502ms) 𝚺=1477.18ms N=87 avg. events=325
  Build attr strings: µ=5.533ms σ=2.824ms (95% CI ≅ 2.709ms–8.358ms) 𝚺=481.39ms N=87 avg. events=2437
       Compute Attrs: µ=1.904ms σ=0.995ms (95% CI ≅ 0.909ms–2.899ms) 𝚺=165.67ms N=87 avg. events=19133
             Segment: µ=5.608ms σ=2.806ms (95% CI ≅ 2.802ms–8.414ms) 𝚺=487.90ms N=87 avg. events=2658
            Advances: µ=0.453ms σ=0.235ms (95% CI ≅ 0.218ms–0.688ms) 𝚺=39.40ms N=87 avg. events=19111
       Combine Attrs: µ=2.619ms σ=1.355ms (95% CI ≅ 1.264ms–3.974ms) 𝚺=227.88ms N=87 avg. events=26
default	16:45:09.171290 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=52.472ms σ=27.540ms (95% CI ≅ 24.931ms–80.012ms) 𝚺=3148.30ms N=60 avg. events=1
   Construct BG runs: µ=0.510ms σ=0.264ms (95% CI ≅ 0.245ms–0.774ms) 𝚺=30.58ms N=60 avg. events=68
             Draw BG: µ=1.448ms σ=0.831ms (95% CI ≅ 0.617ms–2.279ms) 𝚺=86.88ms N=60 avg. events=1
        Construction: µ=20.441ms σ=10.496ms (95% CI ≅ 9.945ms–30.937ms) 𝚺=1226.44ms N=60 avg. events=417
  Build attr strings: µ=6.735ms σ=3.476ms (95% CI ≅ 3.258ms–10.211ms) 𝚺=404.07ms N=60 avg. events=2906
       Compute Attrs: µ=2.348ms σ=1.223ms (95% CI ≅ 1.125ms–3.572ms) 𝚺=140.89ms N=60 avg. events=23324
             Segment: µ=6.719ms σ=3.462ms (95% CI ≅ 3.258ms–10.181ms) 𝚺=403.17ms N=60 avg. events=3233
            Advances: µ=0.554ms σ=0.289ms (95% CI ≅ 0.265ms–0.843ms) 𝚺=33.24ms N=60 avg. events=23298
       Combine Attrs: µ=3.206ms σ=1.662ms (95% CI ≅ 1.544ms–4.869ms) 𝚺=192.39ms N=60 avg. events
default	16:45:14.175829 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=37.340ms σ=21.225ms (95% CI ≅ 16.115ms–58.565ms) 𝚺=3696.62ms N=99 avg. events=1
   Construct BG runs: µ=0.377ms σ=0.220ms (95% CI ≅ 0.158ms–0.597ms) 𝚺=37.37ms N=99 avg. events=52
             Draw BG: µ=0.886ms σ=0.606ms (95% CI ≅ 0.280ms–1.492ms) 𝚺=87.70ms N=99 avg. events=1
        Construction: µ=15.621ms σ=8.295ms (95% CI ≅ 7.327ms–23.916ms) 𝚺=1546.49ms N=99 avg. events=304
  Build attr strings: µ=5.067ms σ=2.750ms (95% CI ≅ 2.317ms–7.817ms) 𝚺=501.63ms N=99 avg. events=2227
       Compute Attrs: µ=1.769ms σ=0.992ms (95% CI ≅ 0.777ms–2.762ms) 𝚺=175.17ms N=99 avg. events=17894
             Segment: µ=5.127ms σ=2.715ms (95% CI ≅ 2.412ms–7.842ms) 𝚺=507.60ms N=99 avg. events=2430
            Advances: µ=0.419ms σ=0.232ms (95% CI ≅ 0.187ms–0.651ms) 𝚺=41.50ms N=99 avg. events=17873
       Combine Attrs: µ=2.397ms σ=1.316ms (95% CI ≅ 1.081ms–3.713ms) 𝚺=237.29ms N=99 avg. events=24
default	16:45:19.235351 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=52.165ms σ=29.370ms (95% CI ≅ 22.795ms–81.534ms) 𝚺=3025.54ms N=58 avg. events=1
   Construct BG runs: µ=0.499ms σ=0.282ms (95% CI ≅ 0.218ms–0.781ms) 𝚺=28.97ms N=58 avg. events=66
             Draw BG: µ=1.585ms σ=0.932ms (95% CI ≅ 0.653ms–2.517ms) 𝚺=91.92ms N=58 avg. events=1
        Construction: µ=19.962ms σ=11.040ms (95% CI ≅ 8.921ms–31.002ms) 𝚺=1157.78ms N=58 avg. events=407
  Build attr strings: µ=6.593ms σ=3.672ms (95% CI ≅ 2.921ms–10.265ms) 𝚺=382.41ms N=58 avg. events=2830
       Compute Attrs: µ=2.291ms σ=1.281ms (95% CI ≅ 1.011ms–3.572ms) 𝚺=132.89ms N=58 avg. events=22663
             Segment: µ=6.579ms σ=3.669ms (95% CI ≅ 2.910ms–10.248ms) 𝚺=381.60ms N=58 avg. events=3149
            Advances: µ=0.534ms σ=0.299ms (95% CI ≅ 0.235ms–0.833ms) 𝚺=30.96ms N=58 avg. events=22638
       Combine Attrs: µ=3.135ms σ=1.755ms (95% CI ≅ 1.380ms–4.890ms) 𝚺=181.83ms N=58 avg. events
default	16:45:24.682360 +0200	iTerm2	-- Precise Timers --
      Total drawRect: µ=57.888ms σ=26.846ms (95% CI ≅ 31.042ms–84.735ms) 𝚺=2373.42ms N=41 avg. events=1
   Construct BG runs: µ=0.555ms σ=0.259ms (95% CI ≅ 0.297ms–0.814ms) 𝚺=22.77ms N=41 avg. events=73
             Draw BG: µ=1.752ms σ=0.968ms (95% CI ≅ 0.784ms–2.720ms) 𝚺=71.84ms N=41 avg. events=1
        Construction: µ=22.116ms σ=10.000ms (95% CI ≅ 12.116ms–32.117ms) 𝚺=906.78ms N=41 avg. events=450
  Build attr strings: µ=7.324ms σ=3.329ms (95% CI ≅ 3.995ms–10.653ms) 𝚺=300.28ms N=41 avg. events=3167
       Compute Attrs: µ=2.537ms σ=1.163ms (95% CI ≅ 1.374ms–3.700ms) 𝚺=104.01ms N=41 avg. events=25052
             Segment: µ=7.314ms σ=3.331ms (95% CI ≅ 3.983ms–10.645ms) 𝚺=299.87ms N=41 avg. events=3522
            Advances: µ=0.589ms σ=0.272ms (95% CI ≅ 0.317ms–0.861ms) 𝚺=24.16ms N=41 avg. events=25024
       Combine Attrs: µ=3.476ms σ=1.588ms (95% CI ≅ 1.888ms–5.065ms) 𝚺=142.52ms N=41 avg. events

I had to switch back to the stable version unfortunately.

The latest beta is faster when you have ligatures disabled. Should be on par with the stable version.

Scrolling in less/more is slow

Designs

Child items ...

Activity

Admin message

Admin message

Scrolling in less/more is slow

Activity