10 ms·

ITerm is great. It really is. But I wish more time was spent on optimizations. People these days seem to forget that terminals are often used for displaying hug

by jwr 12y ago

ITerm is great. It really is. But I wish more time was spent on optimizations. People these days seem to forget that terminals are often used for displaying huge amounts of rapidly scrolling text and that speed is of paramount importance. To put this in perspective, my computer has two CPUs with 4 cores each, 24GB RAM, a graphics card with 1600 Stream Processing Units (engine running at 850MHz) and 1GB of RAM, and yet it scrolls text in a terminal slower than my 386 machine 20 years ago.

tinco 12y ago
Not just fast scrolling text. For some reason there is a noticeable delay when just typing text into a shell in iTerm. I didn't notice it until one day I started Terminal.app for no reason at all, and typing in it gave me that feeling that it was predicting my keystrokes, meaning of course that my brain expected a lag that wasn't there.
- karlkatzke 12y ago
  What's hilarious is that nine or ten years ago, the opposite was true: Terminal lagged greatly, and iTerm was much faster.
  - danudey 12y ago
    I had the good (?) fortune to come into OS X at the end of the 10.3 days (in fact, my Powerbook didn't come with an OS install so I put Debian on it for a week until Tiger was released), so I suppose I missed this phase. When I got Tiger on, Terminal was more than sufficient, and iTerm felt immature and impractical for daily use. I never understood why so many people used it, but reading this, it makes a lot of sense now.
- goblin89 12y ago
  After this thread I've updated iTerm2 to 2.0… and switched back to Terminal. I couldn't believe I could forget about such lag throughout my work. On the other hand, such lag is ever-present with SSH—and now it will subjectively increase as I get used to Terminal again.
rjzzleep 12y ago
i had the same beef with it and i went back to using xquartz with dwm and urxvt. The reason why it's so slow is very simple. It's basically an nstextview derivate. To be fast it needs to fill the buffer and render it offscreen in fixed intervals. a lot of osx programs share this problem. there was an ancient vnc viewer called vncthing that easily beats every osx vnc viewers performance, because of that.
sir-pinecone 12y ago
This might be an unrelated problem, but I find that when I copy a large amount of text and paste it into iTerm, it takes a long time to paste. This often happens when pasting into Vim, so it could be a vim issue. For example, copying the code of a Javascript library. When I do this in a text editor outside of iTerm, it's nearly instantaneous.
- jaredmcateer 12y ago
  Try turning off syntax highlighting and any plugins like jshint that try to operate on a buffer realtime in vim before pasting (or just paste it to an temporary buffer instead of an existing js file) if it's still slow then it's probably iterm and not vim.
- barbs 12y ago
  I have the same issue, and I know it doesn't happen when using Macvim, so it's probably an iTerm problem.
- ZeroGravitas 12y ago
  Vim will type every character you paste, one by one. F12 should switch you to paste mode and paste it as a block, though on my new Mac this was already mapped to some GUI function so I had to disable that for it to work. Some relevant info: http://stackoverflow.com/questions/5585129/pasting-code-into-terminal-window-into-vim-on-mac-os-x http://stackoverflow.com/questions/5585129/pasting-code-into...
  - nobleach 12y ago
    Pasting into a buffer in insert mode is not the best idea. I've remapped <leader>p and <leader>P to paste from the system buffer and it's just as fast as yanking and putting text in Vim.
    - danudey 12y ago
      That doesn't work as well over SSH sessions though, which is where pasting into vim really starts showing its limitations. Vim's normal inefficient behaviour plus a link with latency is an unfortunate circumstance.
rbanffy 12y ago
While text performance is important, when I have to scroll through huge amounts of text it's usually because I made a mistake. If the output of my "fgrep -ri" is too long, it's also useless and I'd better pipe it to another grep or use a better regex.
- jwr 12y ago
  I have tail -f on various logs running, I often run processes that spew massive amounts of debug output (which I then search through), and even ls -al can sometimes be fairly long. There are lots of use cases where you want lots of text. And in this day and age I really want to just dump it all into my terminal, without planning ahead how to work around the slowness.
- Freaky 12y ago
  tmux is my main use-case for a fast terminal. Even something as simple as resizing a split in my main 266x188 session while nothing else is happening makes Terminator (VTE-based) into a juddering laggy mess. urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds. Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.
  - rbanffy 12y ago
    > unusable for over a minute. There is something seriously wrong with your setup. I use Terminator and byobu (with tmux) all day and never experienced what you describe.
    - Freaky 12y ago
      It's responsive and fast for you in a single fullscreen 2560x1600 term while catting a large file in a split? Performance is a lot more reasonable if you're using more traditionally-sized terms and let Terminator manage the splitting. Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.
acdha 12y ago
I've tried iTerm and a few other alternatives periodically over the years and I keep coming back to Terminal.app for performance and stability. It'd be interesting to see how far a performance sprint could take iTerm…
thatmiddleway 12y ago
Did you try out the new iTerm? I was having issues like this, and started using the iterm nightlies about 8 months ago. I've seen considerable performance improvements, and now prefer it over Terminal.app.
- tlrobinson 12y ago
  In case you missed gnachman's comment above, the performance work in the nightlies isn't in 2.0 yet.
  - thatmiddleway 12y ago
    I'd made the comment before he responded, thanks!
gnachman 12y ago
I did a lot of work on performance which you can see in the nightly builds; it was too risky for the 2.0 schedule. We now parse the input stream in a separate thread from where it is rendered. That being said, while the refresh rate is probably lower than it was on your '386, the throughput is undoubtedly higher. If you'd like a higher refresh rate, it's a trivial tweak to a single constant, but in general throughput is more useful.
- jwr 12y ago
  Yes, throughput is what I'm really after, refresh rate is secondary (still nice, but secondary). It's great to hear that this work is happening, thank you! And also thank you for all the work, because gripes aside, iTerm2 is the best tool out there.
yoblin 12y ago
Performance actually seems to be much better in the new version! My standard test is to open a split-screen tmux session and try scrolling man pages.. New version doesn't jump around the page.

by jwr 12y ago

tinco 12y ago

Not just fast scrolling text. For some reason there is a noticeable delay when just typing text into a shell in iTerm. I didn't notice it until one day I started Terminal.app for no reason at all, and typing in it gave me that feeling that it was predicting my keystrokes, meaning of course that my brain expected a lag that wasn't there.

karlkatzke 12y ago
What's hilarious is that nine or ten years ago, the opposite was true: Terminal lagged greatly, and iTerm was much faster.
- danudey 12y ago
  I had the good (?) fortune to come into OS X at the end of the 10.3 days (in fact, my Powerbook didn't come with an OS install so I put Debian on it for a week until Tiger was released), so I suppose I missed this phase. When I got Tiger on, Terminal was more than sufficient, and iTerm felt immature and impractical for daily use. I never understood why so many people used it, but reading this, it makes a lot of sense now.
goblin89 12y ago
After this thread I've updated iTerm2 to 2.0… and switched back to Terminal. I couldn't believe I could forget about such lag throughout my work. On the other hand, such lag is ever-present with SSH—and now it will subjectively increase as I get used to Terminal again.

rjzzleep 12y ago

i had the same beef with it and i went back to using xquartz with dwm and urxvt. The reason why it's so slow is very simple. It's basically an nstextview derivate. To be fast it needs to fill the buffer and render it offscreen in fixed intervals. a lot of osx programs share this problem. there was an ancient vnc viewer called vncthing that easily beats every osx vnc viewers performance, because of that.

sir-pinecone 12y ago

This might be an unrelated problem, but I find that when I copy a large amount of text and paste it into iTerm, it takes a long time to paste. This often happens when pasting into Vim, so it could be a vim issue. For example, copying the code of a Javascript library. When I do this in a text editor outside of iTerm, it's nearly instantaneous.

jaredmcateer 12y ago
Try turning off syntax highlighting and any plugins like jshint that try to operate on a buffer realtime in vim before pasting (or just paste it to an temporary buffer instead of an existing js file) if it's still slow then it's probably iterm and not vim.
barbs 12y ago
I have the same issue, and I know it doesn't happen when using Macvim, so it's probably an iTerm problem.
ZeroGravitas 12y ago
Vim will type every character you paste, one by one. F12 should switch you to paste mode and paste it as a block, though on my new Mac this was already mapped to some GUI function so I had to disable that for it to work. Some relevant info: http://stackoverflow.com/questions/5585129/pasting-code-into-terminal-window-into-vim-on-mac-os-x http://stackoverflow.com/questions/5585129/pasting-code-into...
- nobleach 12y ago
  Pasting into a buffer in insert mode is not the best idea. I've remapped <leader>p and <leader>P to paste from the system buffer and it's just as fast as yanking and putting text in Vim.
  - danudey 12y ago
    That doesn't work as well over SSH sessions though, which is where pasting into vim really starts showing its limitations. Vim's normal inefficient behaviour plus a link with latency is an unfortunate circumstance.

rbanffy 12y ago

While text performance is important, when I have to scroll through huge amounts of text it's usually because I made a mistake. If the output of my "fgrep -ri" is too long, it's also useless and I'd better pipe it to another grep or use a better regex.

jwr 12y ago
I have tail -f on various logs running, I often run processes that spew massive amounts of debug output (which I then search through), and even ls -al can sometimes be fairly long. There are lots of use cases where you want lots of text. And in this day and age I really want to just dump it all into my terminal, without planning ahead how to work around the slowness.
Freaky 12y ago
tmux is my main use-case for a fast terminal. Even something as simple as resizing a split in my main 266x188 session while nothing else is happening makes Terminator (VTE-based) into a juddering laggy mess. urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds. Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.
- rbanffy 12y ago
  > unusable for over a minute. There is something seriously wrong with your setup. I use Terminator and byobu (with tmux) all day and never experienced what you describe.
  - Freaky 12y ago
    It's responsive and fast for you in a single fullscreen 2560x1600 term while catting a large file in a split? Performance is a lot more reasonable if you're using more traditionally-sized terms and let Terminator manage the splitting. Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.

acdha 12y ago

I've tried iTerm and a few other alternatives periodically over the years and I keep coming back to Terminal.app for performance and stability. It'd be interesting to see how far a performance sprint could take iTerm…

thatmiddleway 12y ago

Did you try out the new iTerm? I was having issues like this, and started using the iterm nightlies about 8 months ago. I've seen considerable performance improvements, and now prefer it over Terminal.app.

tlrobinson 12y ago
In case you missed gnachman's comment above, the performance work in the nightlies isn't in 2.0 yet.
- thatmiddleway 12y ago
  I'd made the comment before he responded, thanks!

gnachman 12y ago

I did a lot of work on performance which you can see in the nightly builds; it was too risky for the 2.0 schedule. We now parse the input stream in a separate thread from where it is rendered. That being said, while the refresh rate is probably lower than it was on your '386, the throughput is undoubtedly higher. If you'd like a higher refresh rate, it's a trivial tweak to a single constant, but in general throughput is more useful.

jwr 12y ago
Yes, throughput is what I'm really after, refresh rate is secondary (still nice, but secondary). It's great to hear that this work is happening, thank you! And also thank you for all the work, because gripes aside, iTerm2 is the best tool out there.

yoblin 12y ago

Performance actually seems to be much better in the new version! My standard test is to open a split-screen tmux session and try scrolling man pages.. New version doesn't jump around the page.