Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Docked terminal windows and system performance System
Earlier today, I wanted to start a large download on my home machine. I normally do this via SSH and then the 'wget' (or 'curl') command. However, this particular page was using a PHP submission form, and I just could not get it to work in curl or wget (probably user error!). So I launched 'links', the text-mode browser instead. This worked fine, and the file began downloading.

Since it was a large file, and I had other things to do in the Terminal, I minimized the window to the dock. My machine immediately became very very slow and hard to use. I managed to get a "top -u 10" launched in my Terminal, and noticed that the Dock was using 70% of my CPU!

So I killed the dock process, thinking it had taken off for no good reason. The dock restarted, my minimized window came forward, and all was back to normal. Thinking things were OK now, I minimized the window again, only to have the same problem occur - completely unusable machine.

A little experimentation led me to the cause of the problem. Docked Terminal windows, at least as of 10.1.1 (probably 10.1, too, but I never checked) now "live update" their content in the dock! The 'links' program has a screen display that shows estimated download time remaining, and it updates in real time. So my dock was continuously trying to update that miniaturized window (over a remote connection, no less). Not a good situation! I'm not sure there's a workaround, other than what I did -- drag most of the window off the screen.

If you'd like to see the impact on your machine, read the rest of this article for a simple experiment you can run...

Docked Terminal window experiment:
  • Set your dock to visible and max size (just so you can see what's happening)
  • Open the Terminal
  • Type cd ~/Library/Preferences (so we have a nice long directory to work with)) and then repeat 25 ls -al. If 25 isn't enough time, use a bigger number.
  • Hit the minimize button.
  • Notice the nifty directory listing flowing in the dock.
  • Notice that your machine is quite slow - try clicking on other dock applications, for example, or even try to un-minimize the window.
So while I think the idea of a live updating Terminal window in the dock is interesting (theoretically you could tell when a compile finishes, for example), it would be nice to have the option of disabling it. It's particularly bad when the data in the Terminal is coming from a non-local source.
  • Currently 1.33 / 5
  You rated: 1 / 5 (3 votes cast)

Docked terminal windows and system performance | 9 comments | Create New Account
Click here to return to the 'Docked terminal windows and system performance' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
No noticeable performance hit for me...
Authored by: evands on Nov 16, '01 02:56:00PM

I'm on a G4/500 powerbook with 768 MB RAM... it's indeed a nifty feature that I'm fairly sure is new in 10.1.1... but I don't notice the performance hit you mentioned. Do you have window compression enabled? (Just a random thought).

[ Reply to This | # ]
Window buffer compression and 10.1.1
Authored by: jnm on Nov 16, '01 03:15:13PM
For all those who enabled window buffer compression, the file /Library/Preferences/ is simply replaced during upgrade to 10.1.1 (the date of this file on my computer is Nov 15, which is the date I did the upgrade). This to say the window buffer compression modifications aren't there anymore ! Maybe they ar not needed anymore, who knows ? ;o)

Anyway, on my Dual 450 G4, 512 Mb there's indeed a really impressive speed reduction when I do a nice little loop like this one (sorry, it's bash !) in a minimized Terminal window :

while true; do
echo -n "#"

But there's no real cpu use with normal terminal output.

[ Reply to This | # ]
Authored by: robg on Nov 16, '01 03:39:03PM
On my G4/350, here's the TOP output during my little experiment (a simple "ls -al" repeated 100 times):
9967 Dock 73.2% 0:07.80 3 110 101 3.30M- 11.4M 7.36M- 69.2M
9985 top 12.3% 0:04.06 1 14 15 304K 352K 544K+ 1.45
9985 top 6.3% 0:03.88 1 14 15 304K 352K 540K- 1.45M
etc etc etc
And this is just after a reboot, too. I have NOT re-enabled window buffer compression; I'll try that later and see what happens. -rob.

[ Reply to This | # ]
Window buffer compression and 10.1.1
Authored by: Smackeron on Nov 16, '01 06:58:00PM

After upgrading to 10.1.1 windows compression is still enabled (the lines I added to are still there, and Quartz Debug still show's "C" next to compressed windows.


[ Reply to This | # ]
Guess re workaround
Authored by: klanda on Nov 16, '01 03:34:35PM

I would bet that using the WindowShadeX haxie would not cause the same kind of slowdown, but would still allow you to "hide" the active terminal window.

I noticed the same effect while <update_prebinding -verbose> on my machine. The "live" dock updating is pretty, and pretty useless :)


[ Reply to This | # ]
Been a feature for a while...
Authored by: wyzeguy on Nov 16, '01 07:03:30PM

i've been doin' the minimized terminal window thing for a while. Worked in 10.0.4 if I remember correctly. Don't recall it hitting my system very hard either...maybe they mucked around with something between 10.0.4 and 10.1

[ Reply to This | # ]
WindowShade X a Workaround to This
Authored by: Anonymous on Nov 17, '01 02:10:38PM

Use of the WindowShade X haxie does indeed prevent this from occurring. I just tried your experiment now (I have the minimize set to "hide application") and noted nearly no difference. The dock was a little slow to come up, but the system experienced no slowdown.

[ Reply to This | # ]
Feature, not a bug
Authored by: babbage on Nov 17, '01 04:25:54PM
I would think this isn't something specific to the I remember when OSX was just coming out -- maybe even during the publc beta stage -- there were demos of it running Quicktime movies minimized in the Dock. I would assume that doing that sort of thing took a whole lot of work, as playing full speed video is fairly computationally intensive anyway, and then the system has to dynamically rescale that video to docked size on the fly -- and even more so when using the dock magnification feature.

You're noticing the problem with the Terminal, and maybe it does indeed lack any optimization that Quicktime & other applications might have for docked performance, but I would think that most applications will generate a performance hit when minimized to the dock this way.

The two solutions I can think of would be [a] to run long, non-interactive command line programs in the background (thus avoiding any strain on the Terminal, whether or not minimized), or more generally [b] to hide (cmd-h) applications rather than minimize them, thus avoiding the minimization that seems to be consuming all those CPU cycles.

[ Reply to This | # ]

Feature, not a bug
Authored by: on Nov 28, '01 05:26:09AM

I just upgraded to 10.1.

I was running the CPU Monitor in the Dock when I noticed the load was constantly between 80% and 95%... On a G4 450/DP with 768MB RAM and about 80GB HD total, I found this worrying, since I was only running Eudora and the Terminal App, apart from CPU Monitor.

I was running top in the Terminal, and knowing this would consume _some_ CPU, I stopped it. No change. Terminating Terminal, though, did the trick.

Thing is, I got this load while Terminal wasn't minimized. I haven't checked after this, but you've given me something to think about...


[ Reply to This | # ]