iTerm slows down after many days use

Symptoms: iTerm is becoming sluggish. When attempting to scrollback, it takes about 0.5 seconds before it starts to scroll. Highlighting is a bit laggy too, the drag-select more than double-click select. Sometimes menus are very slow to come up - taking up to 30 seconds for a response! All tabs seem to exhibit the same sluggishness.

Usage: I installed this beta around 21-Feb and have been using it without closing ever since. I put my mac to sleep daily, and have 7 tabs open. I installed imgcat from the get-go and played with that a little (installed from Homebrew using the installer .rb submitted but not accepted for final inclusion.) Haven't changed the profiles any, and other than running into a little curses stuff here and there, nothing out of the ordinary in my terms - just the usual VT emulation stuff.

Haven't tried restarting yet, but will do that shortly.

Required information for bugs. I probably can't help you unless you include this:

• iTerm2 version 2.9.20160206
• OS version 10.10.5 (14F1605)
• Attach ~/Library/Preferences/com.googlecode.iterm2.plist here com.googlecode.iterm2.plist
• Attach a debug log (https://iterm2.com/debuglog) debuglog.txt Debug log context: Enabled logging; clicked on Window menu - took 20 seconds to show up; disabled logging.

I can confirm the same bug. Open for weeks. Just scrolling back after a simple whois is almost unusable. If I open it fresh it works fine (so my current debug log is kinda useless, I'll try to add one after it starts again).

• iTerm2 Build 2.9.20160206
• OSX 10.11.3

How much memory is it using?

Can you create a sample while scrolling? Instructions on sampling are here: https://gitlab.com/gnachman/iterm2/wikis/HowToSample

Mine is using 415MB (189MB compressed.) I went to the app, clicked a menu button, then quickly switch to take a sample. Sample_of_iTerm2_take_2.txt

Today I finally restarted iTerm for the first time since experiencing slowdowns. Rather than Command-Q, I used force quit (mostly to test out the session restore features.) When restarting, all 7 tabs displayed the "could not restore content" bar (https://iterm2.com/why_no_content.html). All sessions did restore however, including open ssh sessions. Not sure if this is useful detail or not, so just adding it for the purposes of full disclosure.

After restart, everything is fast again. I did a find in one window, and scrollback/select works great. Memory usage is only 75MB.

Looks like a leak of tracking regions, although they don't show up in the debug log.

Milestone changed to Ship 3.0

Me too!! For me it seems to be related to clipboard operations or keyboard input. A free running tail on a log file is always fast enough. I get the beachball for a few seconds when this occur and ITerm2 CPU Usage goes >100% Attached sample might show culplrit .. Build 2.9.20160113

Sample_of_iTerm2.txt

@themadsens your sample looks like it's related to saving the session state. When you look in /var/log/system.log, you should see something like this:

2016-03-03 16:03:47.094 iTerm2[35214:4708976] Time to save app restorable state: 0.001731991767883301

Do you see a big number there? Does turning off Prefs>Advanced>Restore window contents at startup help?

@gnachman Thanks for your interest. Unfortunately this option was already off.

For mee too restarting helps a lot ..

Just upgraded to latest beta: 2.9.20160206 Will post again if this continues

Instead of the message above my log has lots of messages like:

Mar  9 20:02:50 fmmbp.lan iTerm2[22443]: (
	    "<PseudoTerminal: 0x7ff059c1d220 tabs=4 window=<PTYWindow: 0x7ff059e24a70 frame=NSRect: {{58, 82}, {792, 945}} title=2. -- FMMBP:003 - ~ -- (bash) alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7ff059c1d220>>",
	    "<PseudoTerminal: 0x7ff059c1bb40 tabs=4 window=<PTYWindow: 0x7ff059f97be0 frame=NSRect: {{851, 82}, {792, 945}} title=3. -- FMMBP:004 - ~/amplex/GridLightApp -- (Vim) alpha=1.000000 isMain=1 isKey=0 isVisible=1 delegate=0x7ff059c1bb40>>",
	    "<PseudoTerminal: 0x7ff059f9b510 tabs=1 window=<PTYWindow: 0x7ff059f94770 frame=NSRect: {{55, 650}, {492, 377}} title=-- FMMBP:008 - ~ -- (bash) alpha=0.000000 isMain=0 isKey=0 isVisible=0 delegate=0x7ff059f9b510>>"
	)
Mar  9 20:02:53 fmmbp.lan mdworker[41314]: iWork MDI raised an exception: Could not read: Is a directory
--
--
	)
Mar  9 20:02:53 fmmbp.lan mdworker[41314]: iWork MDI raised an exception: Could not read: Is a directory
Mar  9 20:02:59 --- last message repeated 2 times ---
Mar  9 20:03:01 fmmbp.lan iTerm2[22443]: Time to encode state for window <PseudoTerminal: 0x7ff059c1d220 tabs=4 window=<PTYWindow: 0x7ff059e24a70 frame=NSRect: {{58, 82}, {792, 945}} title=2. -- FMMBP:003 - ~ -- (bash) alpha=1.000000 isMain=1 isKey=1 isVisible=1 delegate=0x7ff059c1d220>>: 0.005787014961242676
Mar  9 20:03:01 fmmbp.lan iTerm2[22443]: Time to encode state for window <PseudoTerminal: 0x7ff059c1bb40 tabs=4 window=<PTYWindow: 0x7ff059f97be0 frame=NSRect: {{851, 82}, {792, 945}} title=3. -- FMMBP:004 - ~/amplex/GridLightApp -- (Vim) alpha=1.000000 isMain=0 isKey=0 isVisible=1 delegate=0x7ff059c1bb40>>: 0.003246963024139404
Mar  9 20:03:01 fmmbp.lan mdworker[41314]: iWork MDI raised an exception: Could not read: Is a directory

@themadsens , @rixon , and @anazia would you mind trying this build and letting me know if it's any better? It removes mouse tracking so if you use focus follows mouse that won't work, nor will some mouse reporting features.

http://iterm2.com/adhocbuilds/iTerm2-2_9_20160309_214214-adhoc.zip

Hi, I am also experiencing slow down. I find out that it occur when I leave nmonrunning in the background. Atfer a while iTerm2 become very slow. If I close the tab where nmon were running , everything go back to normal. Note that closing the tab may take more than a minute sometimes.

@nicolasbadia Please try the special build I linked in the comment above. Another possible factor is that the activity indicator in the tab bar is slow with the dark theme (this was just fixed for issue #3497 (closed)). Let me know what you find. If the special build does not fix it, please do provide a sample from activity monitor as described at https://gitlab.com/gnachman/iterm2/wikis/HowToSample so I can tell what your specific issue is.

Thx! Works well so far ..

I'll get back later with final call (or sooner if the dreaded beachball resurfaces :-)

/Flemming

@gnachman Thanks for the quick answer. I tried the special build, but I still have issues with long running scripts. Here is a sample from activity monitor: https://gist.github.com/nicolasbadia/8fc1f1649add40cbb46f Let me know if you need more details.

@nicolasbadia Thanks for the feedback. I made a new build with some extra debugging info to figure out where the tracking rects are allocated. Please do this:

1. Install this build: http://iterm2.com/adhocbuilds/iTerm2-2_9_20160314_140236-adhoc.zip

2. Run it for a while until things start to slow down.

3. Turn on debug logging (select the menu item iTerm2 > Toggle Debug Log), and the immediately turn it off again (same menu item)

4. Attach /tmp/debuglog.txt to this issue.

Looks good so far. Of course it's now hard to tell what caused the issue .. Thanks again!!

Status changed to closed