2

When I try to insert the code below in vim using o in a Python file that contains a large dictionary on a single line, line 3 below, my terminal window hangs, and CPU usage spikes to 99%.

I have a Python test file that is similar to this: 

1 from library import module
2 
3 DICT = { <3000-6000 character dictionary on a single line> }
4 KEY = "examplekey"
5 
6 def test_func_on_dict():
7    expected_output = 42
8    output = module.call_function(DICT, KEY)
9    assert output == expected_output

As I type o on line 5 the CPU spikes to 99% and I can't interact with the file. If I delete the large single-line dictionary the speed of vim goes back to normal.

As one of the biggest benefits of Vim is its speed of editing, this has started to grate on me pretty fast. I saw "How to find what slows down vim?" about profiling vim but my problem is on insert and not on the load time. I am using vim-plug.

My .vimrc looks like this: 

call plug#begin('~/.vim/plugged')
Plug 'junegunn/seoul256.vim'
Plug 'junegunn/goyo.vim'
Plug 'junegunn/limelight.vim'
Plug 'beautify-web/js-beautify'
Plug 'vimwiki/vimwiki'
call plug#end()

99.8 is the CPU % in htop:

enter image description here

It has been suggested my question should be closed because it is similar to "Why is pasting a long one-liner very slow in Vim's insert mode?". I don't think the suggest post answers my question because my long line, the large dictionary, is already present in the file. vim is not slow on paste. vim is slow on o insert below the long line. I think there is something to the issue being the time it takes to re-draw everything as noted in "Why is pasting a long one-liner very slow in Vim's insert mode?" but I do not see an obvious solution to the problem as of yet.

Spreading the dictionary out over many lines fixes the issue. Notably, when in :set paste mode, there is no speed issue with the o insert command below the large dict on a single line. Also, whether in visual mode or paste mode, there is no issue when the cursor is above the large dict and o is pressed. However, I am also interested in why this happens, not just what the fix is.

Scott Skiles
  • 3,647
  • 6
  • 40
  • 64
  • 2
    Does this answer your question? [Why is pasting a long one-liner very slow in Vim's insert mode?](https://stackoverflow.com/questions/501332/why-is-pasting-a-long-one-liner-very-slow-in-vims-insert-mode) – grooveplex Jan 11 '20 at 20:54
  • Definitely on the right track, but the long line is already in the file. Is it the same idea behind the problem? Looks like this might be what is going on, from the answer with 6 votes: `That is "normal". It's slow because redrawing the text thousands of times is slow.` https://stackoverflow.com/a/501677/992432 – Scott Skiles Jan 11 '20 at 20:58
  • I think even just moving around still requires Vim to redraw the whole screen. Maybe it also depends on the terminal emulator you are using and the performance in a GPU-accelerated terminal would be faster. – grooveplex Jan 11 '20 at 21:03
  • @here - This is not a duplicate. I am not pasting a large dictionary in vim. I am inserting a line below an already existing large/long dictionary on a single line in vim. *It is not the same question.* I don't want to beat a dead horse, but if you can't see that the question is not the same, but similar, there is no point in carrying on. – Scott Skiles Jan 22 '20 at 23:30
  • @ScottSkiles i cant vote to re-open, but you have my support that this isnt a duplicate. Might raise a custom mod flag about it. PS: what if you try with syntax highlighting off? – D. Ben Knoble Jan 23 '20 at 04:10

1 Answers1

3

The solution, as present in the update, is to avoid having massively long lines.

I would say it’s even poor programming practice not to split the dict across lines for readability.

But it definitely hurts Vim’s performance. I have a CSV file of about 500 rows by 500 columns, and I can still edit with reasonable performance. However, I suspect that joining all the lines together would cause the same issue you see.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
D. Ben Knoble
  • 4,273
  • 1
  • 20
  • 38
  • 2
    Agreed about massively long lines. Write the data to an auxiliary file, formatted as YAML or stick it into a small database, just don't fill your code with huge data blocks. It's not sensible to edit a code file to change data, nor is it sensible to have to navigate around huge data blocks just to maintain the code. – the Tin Man Jan 12 '20 at 05:58
  • This makes sense. I was doing some one-off testing with some sample input. I appreciate the answers & edits! – Scott Skiles Jan 22 '20 at 23:27