ClosestStorm / macvim

Automatically exported from code.google.com/p/macvim
0 stars 0 forks source link

MacVim incremental search slow. #149

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I'm on MacVim 7.2.75 (Snapshot 40) and 8 core MacPro with nVIDIA GeForce
8800 GT and 30'' Apple Cinema Display with 2560x1600 resolution.

If I open a relatively short XML file for editing in MacVim GUI (terminal
version is only slightly faster), and maximize the MacVim window to fill
the entire screen, and then attempt incremental search with / and start
typing the MacVim can't keep up. What I type is echoed with significant
delay (couple of seconds) which does not seem right.

Also scrolling is slow and delayed when I scroll with a wheel mouse. Paging
is not so slow. 

CPU usage while this is happening is significant (about 38% on one of the
cores). 

Let me know if you need any other info. 

Original issue reported on code.google.com by veritas....@gmail.com on 15 Jan 2009 at 12:41

GoogleCodeExporter commented 9 years ago
This is most likely the syntax highlighter that is slowing things down.  Try 
":syntax off" and see if that makes a 
difference.

A problem with XML that I have noticed is that the lines are often very long 
and this causes significant slow 
downs.  I've seen lots of discussions about this on the web but I don't 
remember any links (check Vim tip wiki, 
vim_use list and google in general).

Original comment by bjorn.winckler@gmail.com on 15 Jan 2009 at 4:57

GoogleCodeExporter commented 9 years ago
Yes, turning off the syntax highlighting makes it fast again. 

I tried this on Windows XP with gVIM and 3200x1200 resolution on much slower 
machine,
it's as fast as MacVim with syntax highlighting turned off.

I wonder why the Mac version rendering is so much slower.

Original comment by veritas....@gmail.com on 15 Jan 2009 at 10:57

GoogleCodeExporter commented 9 years ago
I don't know why its that much slower on the Mac, but I have seen similar 
problems before.  There is some part 
of the syntax highlighting code inside Vim that compiles to something very 
slow.  I've tried to profile this but I 
have not managed to figure what exactly is so slow, but it seems that some 
system libraries on the Mac are just 
extremely slow.

At any rate, as far as I can gather the problem is not with the MacVim renderer 
but the regexp code in Vim so I 
don't know what I can do about it.  Still, it might help if you send me the 
file that renders slowly so that I can 
profile what's going on (you can send it directly to my gmail account).

Original comment by bjorn.winckler@gmail.com on 15 Jan 2009 at 11:45

GoogleCodeExporter commented 9 years ago
I don't know if the problem is with the regexp engine. It is perfectly fine 
once you
turn the syntax highlighting off. Would that not indicate that the problem is 
in the
rendering code?

I have attached the XML file (it's really Maple 11 style sheet). But you don't 
need
this file to reproduce the problem.

Also, the slowness of rendering can be seen by simply browsing help files, e.g.

:h index

and make it the only window. Use the mouse wheel to scroll through it. You can 
see
the text being painted.

If you simply page through then it is much faster. But this is a different 
problem
and not so in your face, since I assume most people don't drive VIM with a 
mouse :D.

Original comment by veritas....@gmail.com on 17 Jan 2009 at 2:06

Attachments:

GoogleCodeExporter commented 9 years ago
Veritas: Vim does its syntax highlighting with regex matches. Try

    :e $VIMRUNTIME/syntax/xml.vim

This contains a set of regexen that tell vim how to syntaxcolor xml files.

Bjorn: Since you looked at this, do you have a vague idea where the problem is? 
Might adding dtrace probes to 
some areas of the regex code help to track this down?

Original comment by nicotha...@gmail.com on 17 Jan 2009 at 4:11

GoogleCodeExporter commented 9 years ago
Nico: I don't really have any idea where the problem is.  The only thing I can 
say is that every time I'm profiling 
the string and regexp functions are taking up most of the time.  I once tried 
replacing all the multibyte aware 
string functions for ones that assumed everything was ASCII and made sure they 
could be inlined and this 
resulted in a very noticeable speedup, but nothing groundbreaking.

As for "dtrace probes": I've never used them but I vaguely remember that you 
posted something about dtrace a 
while back.  I've only used the Shark app to do profiling so far.

Original comment by bjorn.winckler@gmail.com on 27 Jan 2009 at 11:39

GoogleCodeExporter commented 9 years ago
I just noticed that for some files (e.g. kiwitobes.com/feeds/python_search.xml 
) syntax highlighting gets a _lot_ 
faster if 'cursorline' is not enabled (or the other way round, gets a lot 
slower if 'cursorline' is set).

Veritas: Do you have 'cursorline' set? Does disabling it help?

Original comment by nicotha...@gmail.com on 5 Feb 2009 at 5:44

GoogleCodeExporter commented 9 years ago
I don't have cursorline in command line version set, but I do in the GUI 
version. 

Also, I have noticed that Snapshot 42 has gotten faster than Snapshot 40 (for 
which I
reported this bug). CPU usage does not spike either. But it still can't keep up 
with
my typing speed. On the other hand it's not as horrible as before.

Original comment by veritas....@gmail.com on 5 Feb 2009 at 10:21