But all of these terminals along with native Mac OS Terminal.app suffer the same slowness while scrolling down a file in vim editor.

As a comparison data point, I can scroll 300 lines in 10 seconds when
I use putty on windows. But all the terminals including native
Terminal.app on Mac OS X 10.6.1 can scroll only 120 lines in 10
seconds.

To many people this may not seem like a big deal, but being a
professional developer that makes a huge difference to me as I can
feel the sluggish left-right-up-down movement in vim.

In your opinion what do you think the root cause may be?

Do you know of any terminal application on Mac OS X, which can match
putty on windows in terms of scroll speed?

And if it's a Mac OS X GUI limitation, when is Apple going to improve this?

Using Vim in Terminal.app, I can easily scroll about 5100 lines in 10 seconds, using ctrl-F or ctrl-B (scroll one page forward or back), if you're trying to move a long distance in a hurry. I get the same speed in MacVim (which can update the screen much faster than Terminal.app), so I'm pretty certain that the limiting factor (at least in MacVim) is the keyboard repeat rate, not Vim's ability to update the screen.

The only way I get roughly 120 lines in 10 seconds, is scrolling Vim (or MacVim) line-at-a-time by holding down "j" or the down arrow, and that's clearly the default keyboard repeat rate (about 12 per second) limiting things.

You can easily adjust the keyboard repeat rate in System Preferences, in the Keyboard pane, by fiddling with "Key Repeat Rate" and "Delay Until Repeat". But I've been using Vi/Vim/MacVim for a loooong time, and have never felt the need to have the keyboard repeat faster; the key (no pun intended) is to use Vim as it was intended...

If you want to move 3 lines down (or up) hit "j" (or "k") 3 times (much faster than waiting for key repeat to kick in). If you want to move 10 or 20 lines down, then maybe hold down "j" ("k") and let it repeat. But if you want to go further, that's the wrong way: ctrl-D (ctrl-U) will take you half a screen Down (Up), ctrl-F (ctrl-B) will take you a full screen Forward/down (Back/up)... holding any of these down will get you somewhere fast. If you're trying to get to somewhere in particular: "]]" ("[[") will jump forward (backward) to the start of the next (previous) function (in C/Obj-C/Perl/Java/Javascript or any other language where "{" by itself at the start of a line indicates the start of a function), or use "/" ("?") to search for some text and "n" to jump to subsequent occurrences until you reach the right one. Or use tags (see ":help tags"), build a tags file for your code, then you can use ":tag yourfunctionname" to jump to a function definition in any file, or sit on the function's name in a call somewhere and hit ctrl-] to jump to the definition (and ctrl-T to jump back to the call). Or even more lazily, in Vim, if you sit on any identifier and hit "*" ("#"), Vim will select that identifier as search text and take you to the next (previous) occurrence, where you can use "n" to keep searching further -- this is more than sufficient in smaller files. And turn on incremental searching and search highlighting (":set incsearch hlsearch", worth putting in your ~/.vimrc), then the search results will be more obvious on the screen.

Finally, nearly everything in Vim (and Vi before it) takes a repeat count argument. If what you want is really to jump 179 lines down, then type "179j" (and if you wanted to get to line 423, that's "423G"). Use the full power of Vim as it was intended, and keyboard repeat rate will never be a limiting factor.

And if you're using Vim on the Mac extensively, you owe it to yourself to check out MacVim -- you can still start it from Terminal.app (an included helper script lets you type "mvim file1 [ file2... ]" at a command line prompt), but it's much more Mac-like -- cut'n'paste and drag'n'drop interact well with other programs, you get real scroll bars (drag those to move through a file really quickly), multiple editing windows, and you can use the mouse for selecting text, along with (practically) unlimited colors for color syntax highlighting (you do use that, right? ":help syntax" or just ":syn on" to switch it on), instead of the 16 colors you're limited to in Terminal.app. And it's fast.

Vim (and MacVim) is the ultimate programmer's editor, if you take the time to really learn how to use it -- it requires the smallest amount of hand movement to make changes (especially since one never has to reach for the mouse), it's insanely customizable/programmable, and it has a very smartly laid out command set -- yes, it has a steep learning curve, but for something that I use 10 hours a day, I'll take easy/powerful to use over easy to learn any day.

Sorry, no. It isn't. Did you read this thread before posting a voodoo-based answer?

I found my Terminal.app is indeed sluggish, though I haven't found other people complaining about this, so I'm guessing the issue is not common.

The issue I'm having is, the Terminal.app became extremely sluggish when it have to render some color texts. When I turn-off syntax coloring, the speed of vim back to normal. When I turn-on syntax coloring, it takes a couple seconds to scroll one line up. And it is not even limited to vim. I experience sluggishness in the shell as well when directory listing is colorized.

It wasn't like this at day 1 of snow leopard, but at some point, I started experience this. At first, I thought it is some sort of network glitches, but when I accidentally turned off the syntax coloring, the speed of vim got much much faster. That is how I came to aware of this. And I've been using X11's xterm instead.

Today, to my surprise, I have changed the theme of the Terminal.app and the issue is suddenly gone. My default theme was Novel and I've changed the default theme as Basic and quit the process and restarted the Terminal.app and color text rendering is not slow anymore. Curiously, if I start another window using Novel theme after the first window is opened as Basic, it is not slow. However, if I changed the default theme as Novel and quit/restart the Terminal.app, it is again slow. So I guess I'll be stick with Basic for now.