Vim is too slow with syntax highlighting
Martin Kopta
I am using ViM every day and there is only few things which bothers
me. One of them is slowness of syntax highlighting. When I work on
something (php, c, c++, perl, ...) I usually have xterm with screen on
fullscreen. That means "speed 38400 baud; rows 78; columns 212;".
When I open a source file with syntax highlighting, it is really
sloooooow to move cursor around, changing text and all redrawing is
painfull. I understand that coloring text by syntax is hard bussines
but hey, I have Intel Core 2 Duo T8300 2.5GHz/800MHz and Intel video
card X3100! Why is it so slow, when it has so much power ready to
work????
Tony Mechelynck
Possibility 1: Try using gvim rather than
Console-Vim-in-maximized-xterm. The present system has vim <=> xterm <=>
screen <=> X (or maybe vim <=> screen <=> xterm <=> X) which means many
more intermediaries (each of which must handle the incoming keypresses
and the outgoing display characters) than in the gvim <=> X case.
Possibility 2: Try keeping your xterm to some size more usual for text
consoles, i.e., 80 columns (exactly) and maybe 60 lines (other common
depths exist, such as 25, 43 or 50 lines).
Possibility 3: If you have slow-redraw problems only (or especially) in
files with very long lines (of several thousand characters), then
reducing the value of the 'synmaxcol' option may help you.
If none of the above makes redrawing faster, then it may be time to look
for something else.
Best regards,
Tony.
--
"The sooner you fall behind, the more time you'll have to catch up!"
Martin Kopta
which is pretty funny), but I am pointing out at the slowness of
syntax highlighting generally. I think, that something must be really
badly solved when it is so slow even on powerfull hardware. Maybe it
is not possible on terminal to have it fast at all, or something else
causes this slowness and can not be improved. I would like to hear
reason why is it so slow and see proof that can not be better. Of
course it is weird to have terminal with 212 columns, but since ViM
and screen can do splits, it is not so rare.
Thanks for all opinions,
Martin
Gabriel Linder
I had an issue like yours recently, and found it was caused by
matchparen. Disabling it by adding "let loaded_matchparen = 1" in
my .vimrc helped me.
Since you are mentionning splits and screens, both can be very low
(for me it works locally on xterm, but when using ssh it is a
nightmare). Better use tabs or buffers for vim, and full windows with
screen.
Tim Chase
> which is pretty funny), but I am pointing out at the slowness of
> syntax highlighting generally. I think, that something must be really
> badly solved when it is so slow even on powerfull hardware. Maybe it
> is not possible on terminal to have it fast at all, or something else
> causes this slowness and can not be improved.
It would help to know some information about where it happens:
Is it worse for particular file-types (such as XML, Python, Perl,
or C) or is it all filetypes?
Are there long lines in the file (and if so, how long)?
How large is the file? KB, MB, or GB? (see ":help limits")
Is the redraw slowness noticeable on certain syntax elements
("worse on matched parens/braces")?
If you're running within X, what video driver are you using?
What terminal emulator are you using (either standard console, or
xterm/rxvt/gnome-terminal/etc)? Does it work better if you use a
"real" console (say, control+alt+F1 instead of a terminal witndo
within your X console which is likely at control+alt+F7 (or F5))
What's the output of
:syn sync
when you notice slowdown?
I do most of my work at home on an old 800mhz laptop with 368
megs of memory (that odd number is 128megs + 256megs - 16megs of
shared video), running Debian. I use my vim within an xterm
(sometimes nested within a "screen" session) with no
unpredictable problems regarding syntax highlighting refresh
times. The only times I have problems are when I've got long
lines -- particularly with large XML files containing no
line-breaks. Tony's suggestion of 'synmaxcol' may help resolve
my problems there. (thanks, Tony, for pointing out this option)
-tim
Charles Campbell
due to syntax highlighting with it. My machine has an NVidia card for
extra video speed, so the source of your difficulty may be that your
video card just can't keep up in fullscreen mode. Alternatively, you
may have a number of plugins/ftplugins that hang on CursorMoved events
(matchparen as mentioned above is a standard one which uses CursorMoved
and CursorMovedI). Do
:au CursorMoved
to see if anything pops up.
In addition to the synmaxcol option, which may be used to speed things
up, another setup uses
syn sync fromstart
which makes syntax highlighting more accurate (see :he syn-sync) at the
price of slowing your display down.
Regards,
Chip Campbell
Raúl Núñez
On Fri, 05 Dec 2008 14:10:28 +0100, Tony Mechelynck dixit:
> On 05/12/08 10:54, Martin Kopta wrote:
> > Hi all ViM lovers,
> >
> > I am using ViM every day and there is only few things which
> > bothers me. One of them is slowness of syntax highlighting. When I
> > work on something (php, c, c++, perl, ...) I usually have xterm
> > with screen on fullscreen. That means "speed 38400 baud; rows 78;
> > columns 212;". When I open a source file with syntax highlighting,
> > it is really sloooooow to move cursor around, changing text and all
> > redrawing is painfull. I understand that coloring text by syntax is
> > hard bussines but hey, I have Intel Core 2 Duo T8300 2.5GHz/800MHz
> > and Intel video card X3100! Why is it so slow, when it has so much
> > power ready to work????
>
> Possibility 1: Try using gvim rather than
> Console-Vim-in-maximized-xterm. The present system has vim <=> xterm
> <=> screen <=> X (or maybe vim <=> screen <=> xterm <=> X) which
> means many more intermediaries (each of which must handle the
> incoming keypresses and the outgoing display characters) than in the
> gvim <=> X case.
I don't know if this applies to xterm, because I use xfce4-terminal and
sakura, both libvte based, but just in case: I switched back from GVim
to console Vim due to slowness. In my case, console Vim under
xfce4-terminal or sakura renders characters much more eye-pleasantly and
much much faster. I had some files that were intolerably slow to edit on
GVim but work OK in console Vim with a terminal emulator.
BTW, I use 100x30 in most of my editing sessions, but even when using
the terminal emulator at full screen the speed is good. I have an Athlon
XP 64 and an old ATI video card, so it is not a bleeding edge equipment.
I haven't tested with xterm recently, but last time I checked the speed
was more or less equal.
Raúl "DervishD" Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...
vs
I have the same problem in xterm only too.
I have disabled matchparen too but it dooes not help.
sis9
try
:set nocursorcolumn
:set nocursorline
or find
- set cursorline
- set cursorcolumn
- highlight CursorLine ...
- higlight CursorColumn ...
in your .vimrc / .gvimrc
and remove/comment them
in my case this solves my proble
> You received this message from the "vim_use" maillist.
> For more information, visit http://www.vim.org/maillist.php
> -~----------~----~----~----~------~----~------~--~---
>
>
>
--
View this message in context: http://old.nabble.com/Vim-is-too-slow-with-syntax-highlighting-tp20850771p26710294.html
Sent from the Vim - General mailing list archive at Nabble.com.
Walkman
!!!
sis9 wrote:
>
> try
> :set nocursorcolumn
> :set nocursorline
>
>
--
View this message in context: http://vim.1045645.n5.nabble.com/Vim-is-too-slow-with-syntax-highlighting-tp1171424p4812212.html