Severe slowness in .html files after switching buffers about vim-css-color

[ap]

Hm. I can’t reproduce this on Linux in gvim 7.2. I opened a 1.6MB HTML file and a small text file; and I have :bnext<CR> mapped to <C-N> so I held Ctrl-N pressed. Vim switched buffers at at least a few dozen frames/sec, even after I held the key for half a minute. Plenty fast and no detectible slowdown.

Maybe the structure of the file is significant? Can you provide me with an example file that exhibits the problem for you? (Upload a gist or something.)

If you do syn list after switching to the buffer with the HTML, does the output get longer every time?

[nemtsov]

$ curl https://raw.github.com/gist/1914468/98e732655ac1c5cacd45220b1198b34ae25a0022/CSS3_Buttons.html > buttons.html
$ vi buttons.html blank
<C-N>   *20

The output doesn't seem to get longer for syn list (although I'm not sure how to get a line count). I also see a big entry for cssColors which definitely doesn't grow.

More info

.vim directory contents

$ .vim tree
.
├── autoload
│   └── pathogen.vim
└── bundle
    └── css-color
        ├── README.md
        ├── after
        │   └── syntax
        │       ├── css.vim
        │       ├── sass.vim
        │       └── stylus.vim
        └── screenshot.png

5 directories, 6 files

.vimrc contents

call pathogen#infect()
syntax on
filetype plugin indent on
map <C-N> :bnext<CR>

[ap]

OK… on one hand that’s great to know, because it means the syntax rule rewriting code is not buggy. On the other hand it means I have no obvious culprit for this.

If you open css.vim and change BufEnter (near the bottom of the file) to BufAdd, does that fix the slowdown for you?

[ap]

Thanks for the sample file. (Note for the record: not much markup, but a ton of inline CSS in the header <style> tag.) I can see on my system that that is slow to switch to, but it’s not unduly so, and more importantly after a minute of holding the key it does not seem to get any slower.

I wonder if MacVim is allocating colours anew every time it switches buffers of something like that?

[nemtsov]

Changing BufEnter to BufAdd fully fixed the slowdown; and also disabled css-color in a way that it only displays colors when I navigate to a line with a hex color.

[ap]

Strange. If I change to BufAdd it makes no difference whatsoever on my system – neither speed nor correctness is affected. So for some reason it is clearing out the highlights… hmm. I’ll have to think about how that could be working.

I wish I had a Mac to test on…

[nemtsov]

Heh, I won't be able to help with getting a mac, but if you create a few branches with ideas—I'll run them.

[hlidotbe]

Hi, just to chime in, I have the same issue on large css files (they should be split but right now it sits at around 9kloc).

While trying to debug step by step I see that PreviewCSSColorInBuffer seems to be called in a loop. Each call is quite fast (around .5 sec) but there's so many of them that it slows down everything.

And I get more or less the same behavior as georgecalm with BufAdd, no highlights until I pass over a line but some lines are still highlighted.

[ap]

Hi, can you give current master a try and report results please.

[hlidotbe]

It seems to work much faster. I still have a ~1 sec delay but it's expected seeing how huge is this file. Much more bearable than the few 5-10 sec before. And all colors seems to be highlighted correctly.

Thanks!

[ap]

What about you, @georgecalm?

[nemtsov]

It does feel faster with the same gist (above), but I now have a different issue (which does go away when css-color is disabled). When I page-dow (C-D) or page-up (C-U), after a few pages the syntax-highlighter becomes disabled. It is only enabled when I use the navigation keys (jkl;). Navigation is also a bit slower when the plugin is enabled.

[ap]

@georgecalm, @hlidotbe, @eMxyzptlk, can you try current master and tell me what is the situation is now?

[ap]

@georgecalm, @hlidotbe, @eMxyzptlk – any news?

[hlidotbe]

Everything seems good for me. The 9kloc file opens a bit slower than smaller file (~1sec) but this is expected and probably not (entirely) related to css-color. Haven't had much time to test thoroughly but the bug mentionned by @georgecalm seems to be gone.

[ap]

Well then. Since I haven’t heard back from anyone else and, after my initial spate of performance work, haven’t had any further complaints in forever, I guess it’s time to consider this issue fixed. Thanks to everyone who participated.