Bug 166042 - gvim is VERY slow repainting
gvim is VERY slow repainting
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-16 01:14 EDT by Pete Zaitcev
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-30 00:44:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
:set all (7.96 KB, text/plain)
2006-08-01 14:14 EDT, Pete Zaitcev
no flags Details

  None (edit)
Description Pete Zaitcev 2005-08-16 01:14:00 EDT
Description of problem:

gvim is extremely slow repainting (about the speed of 9600 baud
terminal, if not slower). This is a slow computer (old P3/500
with NM2500 video), but it's not that slow, and other applications
continue to work normally.

Version-Release number of selected component (if applicable):

vim-minimal-6.3.086-1
vim-common-6.3.086-1
vim-X11-6.3.086-1

How reproducible:

Seems like 100% ...

Steps to Reproduce:
1. Just more up and down with 'j' and 'k'.

Actual results:

Very slow (maybe 100 or 1000 times slower than normal, not just sluggish)

Expected results:

Normal speed.

Additional info:

I was able to do "yum update" after a long break when the update was
failing with this package unresolved or that... So, about 530 packages
were updated. This may be not specific to vim.

However, gnome-terminal works just fine. So it's not fault of gtk2.

I'll have to check on other computers... This one runs 16-bit color.
Comment 1 Karsten Hopp 2005-09-06 05:14:09 EDT
Could you reproduce this on other computers ?
Did you edit a large file with syntax highlighting enabled when the slowdown
occured ? If so, please try if :syntax off speeds things up again.
Comment 2 Pete Zaitcev 2005-09-06 15:44:09 EDT
I only have one other laptop, which runs just fine. It's faster, but
not 100 times faster. It's something else than just the speed.
Let me know if details of X setup may be important.

Highlighting was on, but it's seen on plain text files.
File size does not matter. The number of characters in lines
does though. Texts are slower than C code.
I tried :syntax off as suggested, but it makes no difference.

This is how top looks if I hit ^L a few times:

top - 12:39:11 up  1:00,  3 users,  load average: 0.49, 0.31, 0.13
Tasks:  73 total,   2 running,  71 sleeping,   0 stopped,   0 zombie
Cpu(s): 77.0% us, 22.7% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.3% hi,  0.0% si
Mem:    190092k total,   186584k used,     3508k free,    29432k buffers
Swap:   181204k total,        0k used,   181204k free,    72396k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2042 root      25   0 23640  11m 4520 R 90.5  6.3   1:01.75 X
 2232 zaitcev   16   0 75976  10m 8064 S  8.6  5.8   0:06.52 gvim
 2260 zaitcev   17   0  2020 1000  800 R  0.7  0.5   0:00.22 top
    1 root      16   0  1868  696  600 S  0.0  0.4   0:00.96 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.01 ksoftirqd/0

This is the same if I do it in text mode vi running in gnome-terminal
(same anti-aliased font):

top - 12:41:22 up  1:02,  3 users,  load average: 0.22, 0.28, 0.14
Tasks:  73 total,   1 running,  72 sleeping,   0 stopped,   0 zombie
Cpu(s): 18.8% us,  4.6% sy,  0.0% ni, 76.6% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    190092k total,   183504k used,     6588k free,    29436k buffers
Swap:   181204k total,        0k used,   181204k free,    72132k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2042 root      15   0 22964  11m 4160 S 18.5  6.1   1:15.67 X
 2216 zaitcev   15   0 37968  13m 8568 S  2.6  7.4   0:03.64 gnome-terminal
 2266 zaitcev   16   0  2020 1004  800 R  1.0  0.5   0:00.66 top
 2267 zaitcev   15   0  4516 1300  968 S  0.7  0.7   0:00.11 vi
 2162 zaitcev   15   0 14352 7440 6016 S  0.3  3.9   0:02.44 metacity
 2164 zaitcev   15   0 21492 7668 6332 S  0.3  4.0   0:00.54 gnome-settings-
 2178 zaitcev   15   0  3916 2048 1508 S  0.3  1.1   0:00.39 xscreensaver
 2237 zaitcev   16   0  7268 2524 2076 S  0.3  1.3   0:00.02 sshd
    1 root      16   0  1868  696  600 S  0.0  0.4   0:00.96 init

Refresh on ^L looks completely instantenious, I can't see it.
Comment 3 Karsten Hopp 2005-09-07 09:41:06 EDT
The high CPU usage of X looks more like a rendering problem to me. Are you using
font antialiasing or some special font settings ? 
Is gvim the only slow application or are there others such as firefox which uses
pango, too ?
Comment 4 Pete Zaitcev 2005-09-07 11:28:44 EDT
Same font as in gnome-terminal (I mentioned it before).
Firefox seems to work fine, as much as Deer Park can be expected to work.
Do you think we should bug Mike Harris for profiling tips?
Or perhaps try xmon or something?
Comment 5 Karsten Hopp 2005-10-12 05:15:51 EDT
Is gvim from vim-X11-6.3.090-2 still slow ?
Comment 6 Pete Zaitcev 2005-10-12 18:51:48 EDT
1:6.3.090-2 is the same as before. No improvement.
Comment 7 Karsten Hopp 2006-05-08 07:28:32 EDT
as this isn't reproducable here, hoping that an update somehow fixes this:
Can you please test again with the latest vim packages ? I've built vim-7.0
packages today.
Comment 8 Pete Zaitcev 2006-05-08 16:50:26 EDT
Seems faster now. It works with acceptable speed. However, vi inside vte
(gnome-terminal) is practically instantaneous. It's a very big difference.

Karsten, if you haven't got the cycles to pursue this, I can close.
I just wanted you to be aware.
Comment 9 Karsten Hopp 2006-08-01 09:32:47 EDT
Do you use folding, btw ? This is known to slow down vim.

If not, please attach the output of :set all and maybe your .vimrc (if you're
using a customized vimrc)
Comment 10 Pete Zaitcev 2006-08-01 14:14:50 EDT
Created attachment 133425 [details]
:set all
Comment 11 Pete Zaitcev 2006-08-01 14:21:27 EDT
The main problem here is the enormous regression from the old gvim,
even if it was precipitated by settings. BTW, I never customized anything.
Comment 12 Pete Zaitcev 2006-09-30 00:44:48 EDT
The speed is back in vim-enhanced-7.0.100-1.

Note You need to log in before you can comment on or make changes to this bug.