iTerm 3.5, large buffer and speed

256 views
Skip to first unread message

Emmanuel Blot

unread,
Jul 15, 2024, 11:09:59 AM7/15/24
to iterm2-...@googlegroups.com

Hi,

I’ve noticed since I think I’ve upgraded to iTerm 3.5 (I’m now running iTerm 3.5.3) that iTerm responsiveness highly depends on how many lines have been printed out to the terminal.

Whenever a terminal contains a large buffer, e.g. a long text file has been printed, or tail -f has been used on a long log file, …) any action in iTerm is greatly slowed down. By “large buffer”, I mean in the 100MiB range:

  • typing any char on the command line becomes sluggish
  • printing out more log file becomes very slow
  • cat’ing a long log file into a new or reset terminal starts at full speed, and the longer the file is, the slower the lines are printed out

Resetting the terminal makes iTerm to resume execution at full speed.

It does not seem to be a system memory pressure issue as responsiveness of other iTerm panes do not seem to be impacted when one of them has been filled with that many characters. It also seems that a 200MiB translate into roughly 4GiB of allocated RAM, which seems to be mostly freed once the terminal has been reset.

I don’t recall experiencing this issue with previous releases of iTerm. Is this a know issue?
Is there a way to speed things up? I could reduce the scroll back lines but unfortunately I really do need to look at the whole log file once printed out. Maybe there is a new setting I’m not aware off - or another setting that I should not have enabled?

Thanks,
Emmanuel.

George Nachman

unread,
Jul 18, 2024, 7:20:05 PM7/18/24
to iterm2-...@googlegroups.com
I haven’t experienced exactly wha you’re describing, so there may be something configuration-related going on. It would be helpful to get a sample when catting a long log file. Instructions on making a sample are here: https://gitlab.com/gnachman/iterm2/-/wikis/HowToSample

As for typing on the command line being sluggish, a debug log would be more helpful. Instructions are here: https://iterm2.com/debuglog

--
You received this message because you are subscribed to the Google Groups "iterm2-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iterm2-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iterm2-discuss/C78CE380-67F9-4ABA-9336-890328A4AFE3%40gmail.com.

Chap Harrison

unread,
Jul 18, 2024, 10:59:40 PM7/18/24
to iterm2-discuss
Could https://groups.google.com/g/iterm2-discuss/c/J1y6STeoEEE/m/NBBpkdABAgAJ be related? I was having bad sluggishness in 3.5 with large scrollback buffers, owing (I think) to my prompt. I'm running a 3.5.3beta1 which seems to have fixed the problem.

George Nachman

unread,
Jul 19, 2024, 6:45:56 PM7/19/24
to iterm2-...@googlegroups.com
3.5.0 had a bunch of performance issues. Version 3.5.4beta1 (did you mean that when you wrote 3.5.3beta1? If not you should update) fixes a bunch of them. I’m sure there are still all kinds of improvements that could be made, so finding people who have performance issues is super helpful.

Emmanuel Blot

unread,
Jul 20, 2024, 5:25:46 PM7/20/24
to iterm2-...@googlegroups.com

On 20 Jul 2024, at 0:45, George Nachman wrote:

I’ve installed iTerm2 from https://gitlab.com/gnachman/iterm2/-/issues/11496 (https://iterm2.com/adhocbuilds/iTerm2-0_20240529_160651-adhoc.zip) yesterday and I’ve not been able to reproduce the slowness that I keep experiencing with 3.5.3, although I’ve only used it for a short time.

I’ll try to give it a longer try next week.

I bumped into an unexpected issue (for me as a user): Having both versions of iTerm2 working at once, I was no longer able to use the Python API which is super useful for me, as I clean up the content of one terminal - the one with the very long messages that create the slow down - automatically from another terminal where I launched the app that generates the log messages. Whenever another version of iTerm2 is started up, the already running version of iTerm2 loses its Python API comm capabilities. Not a big deal since I guess we are not supposed to use multiple versions at once anyway, but it reduced my experimentation w/ long log messages.

I do not use a long prompt, although I’m using zsh:

  • without oh-my-zzh or any other zsh improvements,
  • with oh-my-posh

I’ll revert to the 3.5.3 version and capture a debug log. Is there an existing ticket/issue for performance related issue, or should I create a new one?

Side note: it seems the Home and About pages on Patreon are a bit out of date :)

Thanks,
Emmanuel.

George Nachman

unread,
Jul 20, 2024, 8:33:59 PM7/20/24
to iterm2-...@googlegroups.com
If you run two versions concurrently only one of them can listen on the unix domain socket that the Python API uses for communication. I guess the second one wins, which isn’t what I’d have expected!

Please file a new issue at https://iterm2.com/bugs.

Reply all
Reply to author
Forward
0 new messages