Have you noticed that the gvim on the latest distributions (Ubuntu, fedora, CentOS ...etc) is slower than the same gvim on older distributions (RH6/8/9, CentOS 3.X). Today's hardware is faster compared to the HW when, for example, RH 8 was published. Slowliness is, to the certain extend, masked with faster hardware and more RAM.
I did compare old gvim on RH8 on desktop Pentium II (450MHz + 192 MB RAM) with a new gvim on IBM ThinkPad T43 (CPU 2.2GHz + 1 GB RAM).

Old gvim was faster on the older PC hands down. This was very clearly visible during mouse scrolling with sliders and PgUp/PgDn scroling.

Running new gvim on the remote machine over 100Mbits LAN was (is)
two times slower compared to the old gvim running on the same remote machine over the same LAN.

Is there a solution for this ? Yes, fortunately _there_IS_the_solution_.
The solution is very simple.

NO, gvim is not a culprit.
NO, desktop (gnome, kde, xfce...etc ) is not a culprit.

The main culprit is GTK. The new GTK 2.X is painfully slow compared to the old GTK 1.x. Yes I know, the new GTK 2.x has a lot of new great features (atk, pango, i18n, cairo), new nicer widgets... etc.... overall, the new GTK is nicer..... unfortunately, it is a lot slower than the GTK 1.x.

Do you need all these bells and whistles when you edit an ASCII text ?
I do not think so. All you need is a speed, speed and speed. You want to move up and down fast. You do not need to wait for pango to create fantastically beautiful fonts after scrolling the text over the LAN for three lines or scroll the text half the page locally. You want to see in both cases instant smooth scrolling.

So, here is the solution. Follow the instructions to the letter and you will have fast gvim under your fingers at no time. This will be the same fast gvim as it was back in 2001 on RH 6.2 and slower hardware. Since today's hardware is a lot faster, you will enjoy very very fast gvim.

You do NOT need to be root to compile and install new fast gvim.
NOTE: modern distributions do not have anymore OLD GTK toolkit installed.


wget ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2
wget http://ftp.gnome.org/pub/gnome/sourc...-1.2.10.tar.gz
wget http://ftp.gnome.org/pub/gnome/sourc...-1.2.10.tar.gz

tar xvfz glib-1.2.10.tar.gz
cd glib-1.2.10
### where do you want to install fast vi (vim,gvim,gvimdiff.. etc)
mkdir ~/fast_vim
gvim ./gstrfuncs.c
## ... comment out 4 harmless error checkings
## ... search for the string 'g_warning'
./configure --prefix=~/fast_vim
make
make install

cd ..
tar xvfz gtk+-1.2.10.tar.gz
cd gtk+-1.2.10
### bash
export GLIB_CONFIG=~/fast_vim/bin/glib-config
### tcsh
setenv GLIB_CONFIG ~/fast_vim/bin/glib-config
make
make install

cd ..
tar xvfj vim-7.1.tar.bz2
cd vim71
./configure --enable-gui=gtk --with-gtk-prefix=~/fast_vim\
--prefix=~/fast_vim
make
make install


### if you use bash
alias gvim='~/fast_vim/bin/gvim'
### if you use tcsh
alias gvim '~/fast_vim/bin/gvim'
### launch FAST gvim
gvim
## launch OLD slow gvim
\gvim


### that's all folks

Of course GTK1 applications are going to be much faster, it is much more simplistic and was designed to run on hardware we would laugh at today. The same will eventually be true for GTK2, someday we will yearn for the days of GTK2's speed when we are using GTK3.

The point is, GTK1 only appears fast because we are using much more advanced hardware now. If you run a GTK1 application on a machine from that era, it will preform about the same as a GTK2 application on a modern machine.

So clearly there are only two choices here. We can use old and outdated software since it runs faster on our more modern hardware, or we could just get faster hardware. The vast majority of people go for the latter, and with good reason, the price of hardware is very low anymore and using outdated software in general is a bad idea from both a usability and security standpoint.

Yes I know. GTK1 it is much more simplistic... etc etc... but, it is perfectly adequate as a toolkit for the text editor, like gvim. I did not find any deficiency which would prevent me to edit the text very efficiently.

Not true. I did run run latest gvim (7.1), compiled with GTK1.2 on the machine from 1998 (CYRIX CPU 187 MHz with 192 MB RAM). Mouse scrolling was faster (and smoother) on this machine than on DELL 370 ( Pentium III 2.2 GHz with 1 GB RAM. On the DELL I've run gvim 7.1 compiled with GTK 2.4.


First of all. I did __not__ run an outdated and old software. I did run the __latest__ gvim (7.1) compiled with old GTK1.2 on older hardware.
Usability and security was (is) not compromised. ALL te GUI functions are present. NOTHING is missing. On top of that, I can now edit the files in my office from home (via VPN - DSL ) using GUI (gvim) on older lab computers. The editing speed (especially scrolling) is acceptable. Remote editing using gvim with GTK 2.4 on the modern hardware (DELL 370) was painfully slow.

The last version of GTK 1.x (1.2.10) was released in 2001. What exactly would you call that? To say that nothing is missing is of course nonsense, as you are missing all of the functionality and improvements made in the GTK 2 series. That is like saying no functionality is lost between using Firefox 1 and Firefox 3, since they both are capable of browsing the Internet; you are accomplishing the same rough concept but lacking all of the refinements of the later revisions.

Beyond all this, it is arguable that you are going about this whole concept in the wrong way. There is no reason to run GVim itself over the Internet/network to edit the remote file. It would be much faster and make much more sense to mount the remote volume and edit it locally. You are incurring unnecessary overhead by piping the actual GUI over the network rather than the text file itself.

I would call it old software, or 'previous version' software. I would not call it 'outdated' software. The point I want to make in this thread is:
- solving a speed issue with the __latest__ (let me emphasize once again ... ______l_a_t_e_s_t_____ gvim software ( as of today, Jun 9th 2008 version 7.1 )
- writing software require many times to scroll back and forth the text
- gvim 7.1 with GTK 2.X is by factor of 2-3 slower compared to the same gvim 7.1with GTK 1.X (starting the gvim and scrolling up-down)
- there is a speed difference even if I compare gvim 7.1 (GTK 1.X) on old hardware (2000/01) with gvim 7.1 (GTK 2.X) on new hardware (2007/2008)
- the difference in responsiveness editing over the network is more than obvious
- GTK toolkit is just the environment within which the editor (gvim) runs. It can be compiled with MOTIF or even KDE tool kit.
-


I said in my reply: .... but, it is perfectly adequate as a toolkit for the text editor, like gvim. I did not find any deficiency which would prevent me to edit the text very efficiently.

and in my initial post I said:
Yes I know, the new GTK 2.x has a lot of new great features (atk, pango, i18n, cairo), new nicer widgets... etc.... overall, the new GTK is nicer

As you can see, I am aware about the improvements in the GTK arena. Yes, GTK is improved... at the expense of responsiveness and speed.

Again, I do ___not___ miss any functionality when I use gvim with GTK 1.x. Luckily, the gvim programmer(s) wrote the SW in such a way that __nothing__ is missing when you compile gvim against GTK 1.x or GTK 2.x. Kudos to them.

No,I don't. For example, the main task accomplished with a telephone is to talk over the distance. As long this works good enough, I am fine. Yes, I know, I can listen the music with cell phone, or taking pictures or even I can create a short video or browse the net or remotely control my audio system. Yes, all of this can be done and more. But, the main function of the phone is to talk over the distance in a comfortable way.
Same is true with programming editors. We use them to edit the text in a fast and efficient way. They have to be fast and responsive. This is the primary objective. Refinements are very important for the editing engine of the editor, but refinements are just nice for the GUI part of the editor. In case of the gvim, refinements on GUI with GTK 2.x did not bring nothing substantial to the table. Just the opposite, gvim is less responsive and slower compared with gvim (GTK 1.x).


.... hmmmm.... this is very interesting statement... Let's see if it holds the water.
Imagine a company which has a design centers all around the globe (India, Scotland, Finland, Germany, Japan, Korea etc etc). All together, 8000+ people. The he user(s) want to quickly open the file on the remote design center, change line or two at he beginning of the script and couple more lines few screen or two down. Typically, the users are not CL (Command Line) savvy because most of them are familiar only with the MS WINDOWS world. So, what can be done ?
We have to give them GUI interface.
And, BTW, I am talking here about 'real world' company. No, not all of the employees edit the files remotely.... but in each of the design centers there are few of them ( 3-15 ).


You are right... but there are few small technical challenges to be solved:
- regular user does NOT have privileges to mount arbitrary volume locally.
(safety, data flow control and few other annoyances I am not going to elaborate on)
- mounting volumes over the internet is not the best way to go.

- Yes, user do copy files from the remote hosts to their local machine when they need to change substantial portions of the files. Some of them know how to use ftp, few of them use scp ... and other use e-mail.

Have a nice day !

Thanks for this, though I haven't been able to verify if it really does make a difference, I'm sure time and usage will tell.

However, your post wasn't error proof, at least not on my system (kubuntu Hardy).

I was having some errors here so I assumed you forgot the ./configuration operation. Extrapolating from what you had, this is what I did:

cd ..
tar xvfz gtk+-1.2.10.tar.gz
cd gtk+-1.2.10
### bash
export GLIB_CONFIG=~/fast_vim/bin/glib-config
./configuration --prefix=~/fast_vim
make
make install


That seemed to yield some positive results. Until the next step:

I got some more errors here (vim not being able to find the terminal library and some others relating to the path not being absolute). I managed to resolve this by:

-first installing the ncurses-dev library.

sudo apt-get install ncurses-dev

-second, specifying the paths as absolute when configuring:

cd ..
tar xvfj vim-7.1.tar.bz2
cd vim71
./configure --enable-gui=gtk --with-gtk-prefix=/home/mike/fast_vim\
--prefix=/home/mike/fast_vim
make
make install

I hope this helps the next guy.

Thanks for the idea to try to compile Vim for GTK 1.2. How about this (on Ubuntu/Debian):

sudo apt-get build-dep vim-gtk

install 'gtk1.2', 'gtk1.2-common', 'gtk1.2-dev'; then configure the sources from Vim (see ./configure --help); the option

./configure --enable-gui=gtk

will compile Vim for GTK 1.2; then I did 'make' and 'make install'. The result: gVim GTK 1.2 appears to be faster at scrolling than the GTK 2.x version but it is still more sluggish than gVim on my Windows 98 Pentium II 198 MB RAM Notebook. And I'm missing some menu entries in "my GTK1.2 version". *cry*
But I don't care, I try to use Vim under Linux how it is. Maybe the 8th version will be flicker?

Finally it struck me that gVim is much faster (scrolling) when 'radeon' or 'radeonhd' video driver is used and becomes unacceptably slow when the latest ATI 'fglrx' driver (v. 8.6/June 18, 2008) is installed.

There are so many settings for 'fglrx' to play with, cf http://gentoo-wiki.com/HOWTO_ATI_Dri...3_and_newer.29. Nevertheless it is strange that gVim appears to be the only one application which becomes slower under 'fglrx'.