Very slow.

[agscala]

When I run vim with the --startuptime flag, the log printed out says that css-color is taking 4.5 seconds (!!!) to load.

4561.555: sourcing /home/andrew/.vim/bundle-autoupdate/vim-css-color/after/syntax/css.vim

[rogercampos]

I can confirm this, 8 seconds to bootup for me:

8840.780  8613.511  8613.511: sourcing /home/roger/.vim/bundle/vim-css-color/after/syntax/css.vim

[xer0x]

+1, I like this & I want it to be faster.

Is there a way to get it to load only on CSS files? (It makes all files slow for me)

Is there a way to get it to show the document, then color it?

[Floby]

Same here on my notebook. Up to 10~15 seconds to load.

[zerowidth]

Same here. I see a pretty significant CPU spike when loading the plugin.

4737.824  4561.620  4561.620: sourcing /Users/nathan/.vim/after/syntax/css.vim

[zerowidth]

After some digging, helped in part by @ap's refactoring, I narrowed down the performance issue.

This only applies to 256-color terminal vim, not mvim or presumably gvim. Since mvim can handle direct hex values for colors, no translation is needed and everything loads quickly. For 256-color terminals, however, the s:Xterm2rgb function is required for converting RGB values to appropriate color codes. Because it's implemented with a loop scanning all 255 colors for the closest match, and repeated ~150 times, once per e.g. s:SetNamedColor('#40E0D0','Turquoise') call, it takes awhile.

The best solution I can think of is pre-computing the xterm color codes, and altering s:SetNamedColor to accept both the original hex value as well as a precomputed xterm color code. Less dynamic, but it'd be a hell of a lot faster! If not done with vimscript, I found some python code to do the translation as well, at gist 719710, and I'm happy to write a patch.

[Floby]

this looks promising.
I use vim exclusively on a 256 color terminal. Maybe I am the problem =)
Calculating these values in something a bit faster than vimscript should do,
plus calculating them only once per session. As of now, it's recomputing
everything each time I open a CSS buffer.

On 18 May 2011 17:20, aniero <
reply@reply.github.com>wrote:

After some digging, helped in part by @ap's refactoring, I narrowed down the
performance issue.

This only applies to 256-color terminal vim, not mvim or presumably gvim.
Since mvim can handle direct hex values for colors, no translation is needed
and everything loads quickly. For 256-color terminals, however, the
s:Xterm2rgb function is required for converting RGB values to appropriate
color codes. Because it's implemented with a loop scanning all 255 colors
for the closest match, and repeated ~150 times, once per e.g.
s:SetNamedColor('#40E0D0','Turquoise') call, it takes awhile.

The best solution I can think of is pre-computing the xterm color codes,
and altering s:SetNamedColor to accept both the original hex value as well
as a precomputed xterm color code. Less dynamic, but it'd be a hell of a lot
faster! If not done with vimscript, I found some python code to do the
translation as well, at gist 719710, and
I'm happy to write a patch.

Reply to this email directly or view it on GitHub:
#3 (comment)

[ap]

It’s Rgb2xterm that’s slow. I thought about a pre-calculated table for it but unfortunately it would have 24 million entries so the situation would be far worse than now, not better. I’m thinking about how to speed it up.

[agscala]

Since the problem only lies with 256 color terminal users, maybe we can define a set of ranges of colors that translate to one of the 256 colors available rather than pre-calculating all 24 million colors.

[ap]

Any of the 24 million colours may show up in a CSS file so it’s necessary to be able to map any of them down to an xterm colour.

But it’s not necessary to blindly scan the whole 256-colour table each and every time. I’m thinking along the lines that locating the closest spot inside the 6×6×6 RGB cube provided by xterm should require no more than 6+6+6 iterations at worst. That’s more than a 10-fold speed-up. I’m just trying to convince myself that the results this produces are equivalent to the geometric distance scan the script currently uses. (The colour space in the terminal is so limited that there isn’t room for suboptimal choices.)

In the meantime, my fork has a commit that speeds up Rgb2xterm function by between ½ and ⅓, simply by returning immediately if it has reached an exact match.

[zerowidth]

@ap, you're right, I put in the wrong method. It is indeed Rgb2xterm.

Agreed with the 1/2-1/3 speedup as well, that dropped my load time to about 2.75 seconds.

While Rgb2xterm may be slow, the slow load time is dependent entirely on running the 150 or so named css colors through that function, every time. Inline highlighting will also be slow if a file has a lot of arbitrary colors, but that's file dependent, not loading dependent. So I think precalculating just the css named colors initially will alleviate the load time.

I'm all for a faster function, in any case!

[ap]

Try now. (And sorry for rebasing like a rabid hound.)

It should be 5× faster than the original. It still uses the geometric distance scan, but instead of including the entire colour cube in that scan it picks a single colour from it in constant time. So instead of up to 256 iterations, the loop runs at most 41.

I’m still trying to come up with another algorithm for the matching. It should be possible to make it at least 5× faster still. It seems quite unnecessary to scan at all, there should be a data structure that allows picking a colour very much quicker.

And so far it’s all start-up time optimisation. There are other small inefficiencies that won’t yield much speed, but they should still help make it more responsive. (Plus, they’d benefit all users, not just console Vimmers.)

[Floby]

Well, I think you definitely lost me =)
I'll be checking out your pull request. I mainly use vim on my EeePC (Atom)
on which I can see when something runs significantly faster.

On 18 May 2011 23:43, ap <
reply@reply.github.com>wrote:

Try now. (And sorry for rebasing like a rabid hound.)

It should be 5× faster than the original. It still uses the geometric
distance scan, but instead of including the entire colour cube in that scan
it picks a single colour from it in constant time. So instead of up to 256
iterations, the loop runs at most 41.

I’m still thinking about an algorithm to make it faster. It should be
possible to make it at least 5× faster still.

So far it’s only start-up time. There are other small inefficiencies that
won’t yield much speed, but they should still help make it more responsive.
(And they’d benefit all users, not just console Vimmers.)

Reply to this email directly or view it on GitHub:
#3 (comment)

[zerowidth]

Nice work, the startup time in console vim is sub-second now, down from 4.7 seconds (using @ap's fork)

962.834  847.056  847.056: sourcing /Users/nathan/.vim/after/syntax/css.vim

[ap]

OK everyone, try fetching from me again. The GUI version is now over twice as fast as it was before, and the console version is only slower than the GUI by 40% or so. Start-up time for the console version is almost 20× faster than when I started.

At this point it boots so fast and is so responsive that I consider myself done with it.

[Floby]

Thanks a lot. I'll be pulling this soon.
with your previous patch, I get a fine start up time on css files. but guess what. It's still as slow as before on html files (even though these don't contain inline CSS).
:D

[zerowidth]

Awesome, it's down to a third of a second for console vim and .08 sec for mvim. Nice work, thanks!

[Figuera]

Ok, forgive my foolishness, but its simples doesn't work for me.

I put the css.vim archive in ~/.vim/after/syntax/css.vim, open my CSS file in Vim, write my colors but nothing happens.

Am I doing anything wrong? Am I NOT doing something important?

[ap]

That should be all that’s required. What does :set rtp? say?

[Figuera]

runtimepath=/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/
vim72,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,/.vim/after

As usual.

[ap]

Check the output of :scriptnames to see if any regular syntax/css.vim is getting loaded first. If not, then after/syntax/css.vim naturally won’t be loaded either. If that’s the case, then as far as this script is concerned everything works as intended, and the problem is with your configuration.

But if the regular syntax/css.vim is being loaded, then open another issue for this please, instead of resolving this here in this unrelated issue. On my fork or here, doesn’t matter.

[xer0x]

Awesome speed! Nice work ap!

[vjsingh]

Any reason this was never pulled?

[Dieterbe]

maybe there should be an option to only activate on demand, not when opening any css/html file