9 ms·

iTerm2 author here. I'll spend some time looking into iTerm2's latency. I'm sure there are some low-hanging fruit here. But there have also been a handful of c

iTerm2 author here. I'll spend some time looking into iTerm2's latency. I'm sure there are some low-hanging fruit here. But there have also been a handful of complaints that latency was too low—when you hit return at the shell prompt, the next frame drawn should include the next shell prompt, not the cursor on the next line before the new shell prompt has been read. So it's tricky to get right, especially considering how slow macOS's text drawing is. If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. The deprecated core graphics API is significantly faster, but it does a not-so-great job at anything but ASCII text, doesn't support ligatures, etc. Using layers helps on some machines and hurts on others. You also lose the ability to blur the contents behind the window, which is very popular. It also introduces a lot of bugs—layers on macOS are not as fully baked as they are on iOS. So this doesn't seem like a productive avenue. How is Terminal.app as fast as it is? I don't know for sure. I do know that they ditched NSScrollView. They glued some NSScrollers onto a custom NSView subclass and (presumably) copy-pasted a bunch of scrolling inertia logic into their own code. AFAICT that's the main difference between Terminal and iTerm2, but it's just not feasible for a third-party developer to do.

nneonneo 9y ago
What text rendering approach does Terminal.app use, then? Is it also some custom thing? Maybe it does its own font caching - given that the terminal uses fixed-size fonts with simple fonts (fixed-width, no kerning, ligatures, etc.), it seems quite believable that they would avoid the overhead of CoreText (which has to handle a LOT more font complexity). With regards to the shell prompt, I'm almost positive that Terminal.app is using some heuristic to read the prompt after a <return>. A little experiment with a tunable spinloop and a fake prompt in C suggests that Terminal.app waits for about 1ms after a return character before updating the screen: a delay of 950us produces an "instant" prompt, while a delay of 1050us shows the cursor at the start of the next line. As the article notes, a 1ms delay is not really noticeable, and that kind of delay only has to happen in a handful of situations.
- gnachman 9y ago
  Nope, they use core text, same as me. And they do support ligatures, if the font has them. 1ms delay sounds like a reasonable heuristic.
  - nneonneo 9y ago
    I've never seen Terminal.app use ligatures. I just tested with Lucida Grande, which has ff/ffi/ffl ligatures, and Terminal.app didn't use them at all (it just spaced the characters out on a fixed-width grid). Can you give some examples where Terminal.app will use ligatures?
    - gnachman 9y ago
      It uses ligature level 1. fi, etc., are level 2. Try a font like FiraCode to see ligatures on mostly punctuation like ==.
tomjakubowski 9y ago
> If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. Holy cow! I wonder if iTerm2 would benefit from using something like pathfinder[1] for text rendering. I mean, web browsers are able to render huge quantities of (complex, non-ASCII, with weird fonts) text in much less than 150ms on OS X somehow; how do they manage it? Pathfinder is part of the answer for how Servo does it, apparently. [1]: https://github.com/pcwalton/pathfinder https://github.com/pcwalton/pathfinder
- taw55 9y ago
  Another recent new contender: http://sluglibrary.com http://sluglibrary.com This draws the curves directly in the pixel shader.
- bluedino 9y ago
  I have a bunch of iTerm windows open on my MacBook Pro, I don't want my battery life to suffer
  - IamCarbonMan 9y ago
    I can't see how it would. The GPU has to be accessed either way, so doing it directly should be the same or better than through an OSX API.
- pcwalton 9y ago
  > Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. I'm guessing that you're somehow preventing Core Text from taking advantage of its caching. Apple's APIs can be a bit fussy about their internal caches; for example, the glyph cache is (or at least used to be) a global lock, so if you tried to rasterize glyphs on multiple threads you would get stalls. Try to reuse Core Text and font objects as much as possible. Also check to make sure you aren't copying bitmaps around needlessly; copying around 3840x2160 RGBA buffers on the CPU is not fast. :) For a terminal, all you really need to do for fast performance is to cache glyphs and make sure you don't get bogged down in the shaper. Pathfinder would help when the cache is cold, but on a terminal the cache hit rate will be 99% unless you're dealing with CJK or similar. There's a lot lower hanging fruit than adopting Pathfinder, which is undergoing a major rewrite anyway. (I'm the author of Pathfinder.)
rdslw 9y ago
As far as I keep fingers crossed for your efforts, you will not achieve pure text console speed (or even be close to it), linux one the people can easily compare to iterm. There is a lot of reasons, mostly: font rendering, unicode handling, all effects, while pure text is simply copying memory areas and nothing more. full answer: https://unix.stackexchange.com/questions/41225/can-a-terminal-emulator-be-as-fast-as-tty-1-6/41227 https://unix.stackexchange.com/questions/41225/can-a-termina...
- ajnin 9y ago
  You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem. Maybe an opengl or similar renderer would alleviate the actual drawing of the glyphs on the screen.
  - gnachman 9y ago
    A high quality GL renderer would be lovely. It would need to be very capable, and a lot of the time core text spends is on layout rather than rendering, but at least for the plain-ASCII case this would be a huge win. OTOH, it would always look a little off.
  - JohnBooty 9y ago
    You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem Sorry, no. You're totally conflating two orthogonal concepts: throughput and latency. Rendering 60fps (or even 1,000fps) is not remotely the same as achieving low latency. Even if a game is rendering at 60fps, input latency (the time between a user clicking a button and something happening on the screen) is often over 100ms. This article breaks it down... there's a link to it in the original story about terminal latency posted by OP: http://renderingpipeline.com/2013/09/measuring-input-latency/ http://renderingpipeline.com/2013/09/measuring-input-latency...
    - MaulingMonkey 9y ago
Futurebot 9y ago
I've had no problems with latency, but I'd like to add something not in the original article as a latency-adjacent consideration: stability. Stability is an incredibly important attribute, since the output rate of a dead terminal is zero. I switched to iTerm2 recently after repeated Terminal.app slowdowns and crashes, and have no issues doing the exact same things I did in the previous application. Good work.
- eridius 9y ago
  > I switched to iTerm2 recently after repeated Terminal.app slowdowns and crashes Wow, what were you doing? I think I've seen maybe one Terminal.app crash in the past few years, and I'm a very heavy terminal user.
  - nneonneo 9y ago
    I second that - I've never seen Terminal.app outright _crash_. The one thing that will hang it is copying MBs of text out of the buffer, but even then it doesn't crash (just stall for a long time).
  - SomeHacker44 9y ago
    I had the same problem. After using terminal.app exclusively for literally 13 years it became unstable and unusable for me on the new Touch Bar Mac and I switched to iTerm2. That is a noticeably slower program, especially with a big scroll back, but at least it's stable! I have no idea what the cause of the instability was but I couldn't fix it and couldn't tolerate it.
    - ckw 9y ago
      I had a similar issue recently with a touch bar mac. It would crash pretty reliably when deleting lines during interactive rebases. This was in tmux with EDITOR=vim, hitting dd.
    - eridius 9y ago
      You might be happy to know that macOS 10.12.6 (released today) says it "Improves the stability of Terminal app".
epalmer 9y ago
gnachman Thanks for Iterm2. We have many developers using it every day.
gnachman 9y ago
I'm home and was able to run some benchmarks. Looks like 3.1 has significantly better latency than 3.0 did, although there's still room for improvement to reach Terminal's performance. My test results are here: http://iterm2.com/misc/latency/ http://iterm2.com/misc/latency/
- tuananh 9y ago
  Brilliant!
- guessmyname 9y ago
  Off topic — GitHub should use this tool [1] to analyze the latency of Atom. TextEdit - http://i.imgur.com/RIDBuKP.png http://i.imgur.com/RIDBuKP.png Xcode - http://i.imgur.com/PYFLOxH.png http://i.imgur.com/PYFLOxH.png SublimeText - http://i.imgur.com/ZhnQR1v.png http://i.imgur.com/ZhnQR1v.png CotEditor - http://i.imgur.com/J9TPiO6.png http://i.imgur.com/J9TPiO6.png [1] https://github.com/pavelfatin/typometer https://github.com/pavelfatin/typometer
tinix 9y ago
I just wanted to say thanks, for taking the time to dig into this recent issue: https://gitlab.com/gnachman/iterm2/issues/794 https://gitlab.com/gnachman/iterm2/issues/794 in regards to IO lag that is pretty relevant to this discussion. I was pretty surprised to realize how much faster Terminal was in those tmux side-by-side videos.
thinkMOAR 9y ago
Good to read you are going to spend some time on it. Because iTerm2 is my favourite on OSX and the different vs terminal.app surprised me quite a bit. Will you be releasing beta version or users to test or any updates will go to the main release version?
JdeBP 9y ago
Alacritty has an interesting reason for tearing: * https://github.com/jwilm/alacritty/issues/598 https://github.com/jwilm/alacritty/issues/598
johnwilkesbooth 9y ago
Any thoughts on rewriting iTerm2 in Rust?
- FreeFull 9y ago
  I don't honestly see how that would help. A rewrite is a lot of work, and it doesn't seem the bottlenecks here are language-specific anyway.
cerberusss 9y ago
Thanks for iTerm2. When I moved from Linux to macOS, I installed it and loved it. It's one of those apps that I simply always have open.

nneonneo 9y ago

What text rendering approach does Terminal.app use, then? Is it also some custom thing? Maybe it does its own font caching - given that the terminal uses fixed-size fonts with simple fonts (fixed-width, no kerning, ligatures, etc.), it seems quite believable that they would avoid the overhead of CoreText (which has to handle a LOT more font complexity). With regards to the shell prompt, I'm almost positive that Terminal.app is using some heuristic to read the prompt after a <return>. A little experiment with a tunable spinloop and a fake prompt in C suggests that Terminal.app waits for about 1ms after a return character before updating the screen: a delay of 950us produces an "instant" prompt, while a delay of 1050us shows the cursor at the start of the next line. As the article notes, a 1ms delay is not really noticeable, and that kind of delay only has to happen in a handful of situations.

gnachman 9y ago
Nope, they use core text, same as me. And they do support ligatures, if the font has them. 1ms delay sounds like a reasonable heuristic.
- nneonneo 9y ago
  I've never seen Terminal.app use ligatures. I just tested with Lucida Grande, which has ff/ffi/ffl ligatures, and Terminal.app didn't use them at all (it just spaced the characters out on a fixed-width grid). Can you give some examples where Terminal.app will use ligatures?
  - gnachman 9y ago
    It uses ligature level 1. fi, etc., are level 2. Try a font like FiraCode to see ligatures on mostly punctuation like ==.

tomjakubowski 9y ago

> If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. Holy cow! I wonder if iTerm2 would benefit from using something like pathfinder[1] for text rendering. I mean, web browsers are able to render huge quantities of (complex, non-ASCII, with weird fonts) text in much less than 150ms on OS X somehow; how do they manage it? Pathfinder is part of the answer for how Servo does it, apparently. [1]: https://github.com/pcwalton/pathfinder https://github.com/pcwalton/pathfinder

taw55 9y ago
Another recent new contender: http://sluglibrary.com http://sluglibrary.com This draws the curves directly in the pixel shader.
bluedino 9y ago
I have a bunch of iTerm windows open on my MacBook Pro, I don't want my battery life to suffer
- IamCarbonMan 9y ago
  I can't see how it would. The GPU has to be accessed either way, so doing it directly should be the same or better than through an OSX API.
pcwalton 9y ago
> Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. I'm guessing that you're somehow preventing Core Text from taking advantage of its caching. Apple's APIs can be a bit fussy about their internal caches; for example, the glyph cache is (or at least used to be) a global lock, so if you tried to rasterize glyphs on multiple threads you would get stalls. Try to reuse Core Text and font objects as much as possible. Also check to make sure you aren't copying bitmaps around needlessly; copying around 3840x2160 RGBA buffers on the CPU is not fast. :) For a terminal, all you really need to do for fast performance is to cache glyphs and make sure you don't get bogged down in the shaper. Pathfinder would help when the cache is cold, but on a terminal the cache hit rate will be 99% unless you're dealing with CJK or similar. There's a lot lower hanging fruit than adopting Pathfinder, which is undergoing a major rewrite anyway. (I'm the author of Pathfinder.)

rdslw 9y ago

As far as I keep fingers crossed for your efforts, you will not achieve pure text console speed (or even be close to it), linux one the people can easily compare to iterm. There is a lot of reasons, mostly: font rendering, unicode handling, all effects, while pure text is simply copying memory areas and nothing more. full answer: https://unix.stackexchange.com/questions/41225/can-a-terminal-emulator-be-as-fast-as-tty-1-6/41227 https://unix.stackexchange.com/questions/41225/can-a-termina...

ajnin 9y ago
You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem. Maybe an opengl or similar renderer would alleviate the actual drawing of the glyphs on the screen.
- gnachman 9y ago
  A high quality GL renderer would be lovely. It would need to be very capable, and a lot of the time core text spends is on layout rather than rendering, but at least for the plain-ASCII case this would be a huge win. OTOH, it would always look a little off.
- JohnBooty 9y ago
  You only need to be as fast as one screen refresh period, 1/60th of a second usually, plenty of cycles on modern cpus. Many games that are very complex graphically do it without problem Sorry, no. You're totally conflating two orthogonal concepts: throughput and latency. Rendering 60fps (or even 1,000fps) is not remotely the same as achieving low latency. Even if a game is rendering at 60fps, input latency (the time between a user clicking a button and something happening on the screen) is often over 100ms. This article breaks it down... there's a link to it in the original story about terminal latency posted by OP: http://renderingpipeline.com/2013/09/measuring-input-latency/ http://renderingpipeline.com/2013/09/measuring-input-latency...
  - MaulingMonkey 9y ago

Futurebot 9y ago

I've had no problems with latency, but I'd like to add something not in the original article as a latency-adjacent consideration: stability. Stability is an incredibly important attribute, since the output rate of a dead terminal is zero. I switched to iTerm2 recently after repeated Terminal.app slowdowns and crashes, and have no issues doing the exact same things I did in the previous application. Good work.

eridius 9y ago
> I switched to iTerm2 recently after repeated Terminal.app slowdowns and crashes Wow, what were you doing? I think I've seen maybe one Terminal.app crash in the past few years, and I'm a very heavy terminal user.
- nneonneo 9y ago
  I second that - I've never seen Terminal.app outright _crash_. The one thing that will hang it is copying MBs of text out of the buffer, but even then it doesn't crash (just stall for a long time).
- SomeHacker44 9y ago
  I had the same problem. After using terminal.app exclusively for literally 13 years it became unstable and unusable for me on the new Touch Bar Mac and I switched to iTerm2. That is a noticeably slower program, especially with a big scroll back, but at least it's stable! I have no idea what the cause of the instability was but I couldn't fix it and couldn't tolerate it.
  - ckw 9y ago
    I had a similar issue recently with a touch bar mac. It would crash pretty reliably when deleting lines during interactive rebases. This was in tmux with EDITOR=vim, hitting dd.
  - eridius 9y ago
    You might be happy to know that macOS 10.12.6 (released today) says it "Improves the stability of Terminal app".

epalmer 9y ago

gnachman Thanks for Iterm2. We have many developers using it every day.

gnachman 9y ago

I'm home and was able to run some benchmarks. Looks like 3.1 has significantly better latency than 3.0 did, although there's still room for improvement to reach Terminal's performance. My test results are here: http://iterm2.com/misc/latency/ http://iterm2.com/misc/latency/

tuananh 9y ago
Brilliant!
guessmyname 9y ago
Off topic — GitHub should use this tool [1] to analyze the latency of Atom. TextEdit - http://i.imgur.com/RIDBuKP.png http://i.imgur.com/RIDBuKP.png Xcode - http://i.imgur.com/PYFLOxH.png http://i.imgur.com/PYFLOxH.png SublimeText - http://i.imgur.com/ZhnQR1v.png http://i.imgur.com/ZhnQR1v.png CotEditor - http://i.imgur.com/J9TPiO6.png http://i.imgur.com/J9TPiO6.png [1] https://github.com/pavelfatin/typometer https://github.com/pavelfatin/typometer

tinix 9y ago

I just wanted to say thanks, for taking the time to dig into this recent issue: https://gitlab.com/gnachman/iterm2/issues/794 https://gitlab.com/gnachman/iterm2/issues/794 in regards to IO lag that is pretty relevant to this discussion. I was pretty surprised to realize how much faster Terminal was in those tmux side-by-side videos.

thinkMOAR 9y ago

Good to read you are going to spend some time on it. Because iTerm2 is my favourite on OSX and the different vs terminal.app surprised me quite a bit. Will you be releasing beta version or users to test or any updates will go to the main release version?

JdeBP 9y ago

Alacritty has an interesting reason for tearing: * https://github.com/jwilm/alacritty/issues/598 https://github.com/jwilm/alacritty/issues/598

johnwilkesbooth 9y ago

Any thoughts on rewriting iTerm2 in Rust?

FreeFull 9y ago
I don't honestly see how that would help. A rewrite is a lot of work, and it doesn't seem the bottlenecks here are language-specific anyway.

cerberusss 9y ago

Thanks for iTerm2. When I moved from Linux to macOS, I installed it and loved it. It's one of those apps that I simply always have open.