`relativenumber` slows down moving with long lines

[GoogleCodeExporter]

What steps will reproduce the problem?
1. wget 
https://gist.githubusercontent.com/blueyed/b098ff662b2963621ec0/raw/a6f5a88f43c3
f55a48bf89ddcad08c86ed2e67c9/test.diff
2. vim -u NONE -N -c 'set nowrap relativenumber' -c 'syn on' test.diff

What is the expected output? What do you see instead?

Moving up/down using k/j is slow.
It's ok with `norelativenumber`.

This indicates that redrawing the numbers triggers processing of the long, 
non-wrapped line somehow, which should get optimized.

What version of the product are you using? On what operating system?
7.4.560 (hg)

Please provide any additional information below.

You might get hit by https://code.google.com/p/vim/issues/detail?id=309 before 
- I've patched syntax/diff.vim locally to make it behave better.

Original issue reported on code.google.com by dhahler@gmail.com on 6 Jan 2015 at 8:30

[GoogleCodeExporter]

This happens through `redraw_for_cursorline`, and is caused by redrawing being 
rather slow with long lines.

See also `:for i in range(0, 100) | redraw! | endfor` - it's fast with the long 
line being removed, but slow with the initial test file.

Original comment by dhahler@gmail.com on 6 Jan 2015 at 8:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I am attaching the callgraph from `valgrind --tool=callgrind --dump-instr=yes 
--simulate-cache=yes --collect-jumps=yes vim test.diff` (exported through 
kcachegrind).

This is for starting Vim and then moving three (or four?) lines down.

It might make sense to cache the results from `win_line` (or something similar) 
and re-use them as long as the buffer does not change.

Original comment by dhahler@gmail.com on 6 Jan 2015 at 9:12

• Added labels: ****
• Removed labels: ****

Attachments:

• callgraph.dot.ps