Slow performance while editing bigger files

[maxigaz]

I have a .org file converted from .md with Pandoc that is over 800 lines long. I have 1-2 second long lags whenever I open it with Neovim 0.1.7, make changes in it (such as the insertion of headings), or even switch between insert and normal modes. I don’t have this problem in the case of files with other formats.

[mturquette]

Thanks for the awesome plugin jceb!

Can confirm slow behavior with larger files. My todo.org has over 1,500 lines (mostly notes and not todo items, thankfully) and it's become almost unusable due to lag at operations such as:

any operations using visual mode are terrible
changing from normal mode to insertion mode is terrible

I can break up my todo.org into smaller files but that is a hack. It's well organized and I hope to avoid doing it.

Any hints on how I can profile the plugin to see where the slow downs/latencies are occuring and report my finding back here?

[akstrfn]

In my tests some functions are called too many times, unfortunatelly I don't think there is a easy fix for this atm as some of this parts require a lot of refactoring.

[jceb]

Yes, the issue is not that easy to solve right now. The main issue is that <Tab> opens and closes sub-headings. In order to support this feature, I had to implement a representation of the document in Python which is also used for many other actions. This representation takes a while to build and it also has to be rebuilt because it isn't fully updated when text is changed in vim. It will take time to refactor vim-orgmode and take out the slow parts.

[erahhal]

Is there a way to make calls asynchronous until (and even after) the refactor is complete?

[jceb]

@erahhal it might be possible if someone decided to invest time into this issue. So far I'm not aware of anyone who stepped forward to do it.

[petRUShka]

Workaround: use vim instead, it's about 6x times faster with vim-orgmode.

The are two reasons for bad performance:

1. Going back-and-forth from Vim to Python instead of handling batch buffer (could be fix here in vim-orgmode).

Quotation of Neovim developer:

Note that vim-orgmode could probably fix this by simply getting buffer contents in a batch, doing its work, then sending the updates in a batch. Instead of going back-and-forth from Vim to Python.

2. Bad performance of neovim\python combination (could be fixed in neovim).

See neovim/neovim#11143

[petRUShka]

Quotation from profile log (opening file with ~10000 lines):

FUNCTION  provider#python3#Call()
    Defined: /usr/share/nvim/runtime/autoload/provider/python3.vim line 26
Called 10007 times
Total time:  14.891349
 Self time:  14.840843

So python call per each line. Which is suggested by neovim developer to reduce to one python call per buffer instead.

[XVilka]

@petRUShka are you willing to send a PR? I will review and merge it.

[petRUShka]

@XVilka, I'm really thinking about it but I'm pretty unfamiliar with codebase, so that is the major hitch...