New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: cache syntax highlighting to improve 'relativenumber' scroll performance #1735

Open
bluz71 opened this Issue May 30, 2017 · 7 comments

Comments

Projects
None yet
6 participants
@bluz71

bluz71 commented May 30, 2017

Hello Vim team,

Spawning a new feature request from the existing Ruby high CPU usage #282 issue. Note, the vim-ruby #243 issue is fundamentally the same issue as well.

Basically the issue boils down to syntax highlighting needing to be calculated for every visible line when scrolling up or down with relativenumber enabled. The more lines visible and the slower the host CPU the worse the performance hit especially for languages with complex syntax highlighters such as Ruby.

In issue #282 Bram said this (Dec 2015):

When moving the cursor around, with 'relativenumber' or 'cursorcolumn'
set, cause a full redraw, because every line changes. I'm wondering if
it is possible to cache the result of syntax highlighting. It would
require storing the "attr" value, before it's mixed with other
attributes, such as from 'cursorcolumn'. So long as we don't scroll the
screen update would be much faster. These days memory is plenty, thus
that isn't a problem.

As soon as you page forward it's just as slow, of course, thus making
the syntax highlighting faster is still desired.

I suspect, if implemented, that this suggestion indeed would greatly help scroll performance for those of us who enable relativenumber. A new setting possibly? cachesyntax?

I leave it to the Vim masters to either: do this, or not do this, or schedule later, or close if too hard.

Thank you.

@mgraham

This comment has been minimized.

Show comment
Hide comment
@mgraham

mgraham Aug 24, 2017

Ok, I don't know the internals of cursorline or vim's syntax highlighting, but it seems to me that it should be possible to completely separate cursorline highlighting from syntax highlighting?

Usually, the cursorline just changes the background colour for the current line. So...

  • when drawing the line the cursor is on, set the background colour to the highlight colour.
  • when drawing any other line set the background colour to the regular background colour.

I don't understand why the entire screen's syntax highlighting needs to be recalculated because the background colour of one line gets toggled.

mgraham commented Aug 24, 2017

Ok, I don't know the internals of cursorline or vim's syntax highlighting, but it seems to me that it should be possible to completely separate cursorline highlighting from syntax highlighting?

Usually, the cursorline just changes the background colour for the current line. So...

  • when drawing the line the cursor is on, set the background colour to the highlight colour.
  • when drawing any other line set the background colour to the regular background colour.

I don't understand why the entire screen's syntax highlighting needs to be recalculated because the background colour of one line gets toggled.

@mgraham

This comment has been minimized.

Show comment
Hide comment
@mgraham

mgraham Sep 8, 2017

For instance, the screen's syntax highlighting does not seem to need to be recalculated every time a visual text selection changes.

mgraham commented Sep 8, 2017

For instance, the screen's syntax highlighting does not seem to need to be recalculated every time a visual text selection changes.

@neoadventist

This comment has been minimized.

Show comment
Hide comment
@neoadventist

neoadventist Jan 5, 2018

Awesome! I've been wondering why my screen has been flickering every time I go to the next line. I would love to know how to fix this! @mgraham @bluz71

neoadventist commented Jan 5, 2018

Awesome! I've been wondering why my screen has been flickering every time I go to the next line. I would love to know how to fix this! @mgraham @bluz71

@bluz71

This comment has been minimized.

Show comment
Hide comment
@bluz71

bluz71 Jan 8, 2018

@neoadventist,

The enhancement needs to happen inside Vim & Neovim, so for now there is not much you can do except disable relativenumber.

bluz71 commented Jan 8, 2018

@neoadventist,

The enhancement needs to happen inside Vim & Neovim, so for now there is not much you can do except disable relativenumber.

Inglorion-G added a commit to Inglorion-G/dotfiles that referenced this issue Jan 18, 2018

Fix high latency for ruby files
Having relative line numbers enabled and using regex engine 0 or 2
causes high latency in ruby files. There is an open issue to track this:
vim/vim#1735.

This sets the regex engine to 1, which allows for relative line numbers.
@her

This comment has been minimized.

Show comment
Hide comment
@her

her Apr 21, 2018

If you comb through the various postings about this issue across the internet these suggestions come up frequently as a fix:

set ttyfast
set lazyredraw
set regexpengine=1

However these I suspect are actually just fixing people's issues with 3rd party plugins.

The real fix for this is:

set norelativenumber

I think this feature is simply broken when applied to ruby filetypes due to what @bluz71 and @brammool already mentioned.

Hopefully this helps others as it took me some time to find the culprit. Cheers.

her commented Apr 21, 2018

If you comb through the various postings about this issue across the internet these suggestions come up frequently as a fix:

set ttyfast
set lazyredraw
set regexpengine=1

However these I suspect are actually just fixing people's issues with 3rd party plugins.

The real fix for this is:

set norelativenumber

I think this feature is simply broken when applied to ruby filetypes due to what @bluz71 and @brammool already mentioned.

Hopefully this helps others as it took me some time to find the culprit. Cheers.

@bluz71

This comment has been minimized.

Show comment
Hide comment
@bluz71

bluz71 Apr 22, 2018

@her,

I agree with:

set ttyfast
set regexpengine=1

However, enabling lazyredraw has lead to weird redraw and slow character deletion issues in my experience. I experimented with it quite a bit and in the end concluded that it is best left disabled.

I also recommend this setting:

set synmaxcol=200

Only syntax highlight the first 200 chars of a line. Very long lines are a killer with relativenumber.

The Ruby syntax highlighter contains hundreds of regexps, multiple by the number of visible lines can equal very bad scroll performance with relativenumber. Caching syntax highlighting is my number one most wanted Vim enhancement. Good to see the first post of this issue now with 62 likes (and slowly growing).

bluz71 commented Apr 22, 2018

@her,

I agree with:

set ttyfast
set regexpengine=1

However, enabling lazyredraw has lead to weird redraw and slow character deletion issues in my experience. I experimented with it quite a bit and in the end concluded that it is best left disabled.

I also recommend this setting:

set synmaxcol=200

Only syntax highlight the first 200 chars of a line. Very long lines are a killer with relativenumber.

The Ruby syntax highlighter contains hundreds of regexps, multiple by the number of visible lines can equal very bad scroll performance with relativenumber. Caching syntax highlighting is my number one most wanted Vim enhancement. Good to see the first post of this issue now with 62 likes (and slowly growing).

@folofjc

This comment has been minimized.

Show comment
Hide comment
@folofjc

folofjc Jul 26, 2018

I have this issue and do not do pgp or ruby syntax highlighting. It also just started happening recently, so might have come from an update.

folofjc commented Jul 26, 2018

I have this issue and do not do pgp or ruby syntax highlighting. It also just started happening recently, so might have come from an update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment