VimOrganizer severly slows down switching buffers

[kynan]

Usually I have many buffers open in vim simultaneously (mostly in tabs) and frequently switch back and forth between those.

Immediately after enabling org mode as per instruction in INSTALL.txt I noticed a considerable slowdown (~0.5sec) when switching from and to a buffer with a .org file loaded. This is so severe that it makes VimOrganizer effectively unusable to me.

Have you noticed this slowdown and/or made some profiling identifying why this takes so long?

Could this be caused by a conflict with another plugin? Or not having installed the recommended plugins from 4.-6. in INSTALL.txt (which I haven't)?

Is it possible to load only a subset of the features (I mainly need syntax highlighting since I only use the markup features) and thereby get better performance?

[hsitz]

On Tue, Nov 29, 2011 at 5:58 AM, Florian Rathgeber <
[email protected]

wrote:

Usually I have many buffers open in vim simultaneously (mostly in tabs)
and frequently switch back and forth between those.

Immediately after enabling org mode as per instruction in INSTALL.txt I
noticed a considerable slowdown (~0.5sec) when switching from and to a
buffer with a .org file loaded. This is so severe that it makes
VimOrganizer effectively unusable to me.

Have you noticed this slowdown and/or made some profiling identifying why
this takes so long?

Hard to say without knowing more, but I expect what you're seeing is the
slowdown caused by Vim needing to recalculate folds for the entire buffer
whenever the buffer is loaded into a window. Actually, that is not quite
true since VimOrganizer should be managing things so the foldexpression
calculations do not happen upon first load, only first time the file is
viewed with a need for the folds.

The slowdown is mostly a function of the size of the file, the number of
heading folds. A 0.I expect a 0.5 second fold calculation time would be
what you'd see when folds were initialized for a 2,000 line file.

So long as you use tabs the slowdown should happen only once for each file
you're working with. That is, once folds are initialized switching between
files/tabs should be instantaneous so long as files are kept open in a
window on each tab. This is the reason that VimOrganizer was made using
tabs, since you cannot avoid the slowdown if you merely switch between
.org buffers in same window.

Thanks for asking this question, you're first person to point it out. I
need to get this clarified in the documentation. VimOrganizer is
constructed so that moving between .org buffers is mostly done using the
Agenda, which will automatically organize and navigate between the files on
different tabs. As I said, slowdown occurs only first time a file is
visited on a tab. I will be adding alternate mechanism to move between org
files (each still on different tab) without use of Agenda, but merely
switching org buffers within same window is NOT something that is
recommended. (All of this slowdown is well-known by me and result of the
way Vim works with folds, which is entirely different from emacs. I've
spent a lot of time profiling to get faster behavior of initializing
folds. Because it should occur only once per file per vim session it seems
to me current performance is quite acceptable, but in some cases you still
need to know how to minimize/work around. . . )

Could this be caused by a conflict with another plugin? Or not having

installed the recommended plugins from 4.-6. in INSTALL.txt (which I
haven't)?

Without knowing more I'd say it sounds like the fold-expression
calculations that are causing the slowdown.

Is it possible to load only a subset of the features (I mainly need syntax
highlighting since I only use the markup features) and thereby get better
performance?

The fold calculations are only thing I can think of. It would be fairly
easy thing to disable folding in VimOrganizer but since managing of the
folds in an outline structure is its main feature I question why you would
even want to use it then.

Please do let me know more about the type of files you're working with
(line length and content) as well as whether you are experience slowdowns
after first view of an org file in its own tab.

-- Herb

[kynan]

I was working with files of a few 100 lines (only outline text). I noticed that the delay only occurs when I use my custom key binding to switch tabs (and not using gt/gT):

",n to go to next tab
nnoremap <silent> <leader>n :silent :tabnext<CR>
",p to go to next tab
nnoremap <silent> <leader>p :silent :tabprevious<CR>

I couldn't quite figure out why that could be. It does also happen when switching to the tab for the 2nd and subsequent times.

[hsitz]

On Fri, Dec 2, 2011 at 5:24 PM, Florian Rathgeber <
[email protected]

wrote:

I was working with files of a few 100 lines (only outline text). I noticed
that the delay only occurs when I use my custom key binding to switch tabs
(and not using gt/gT):

",n to go to next tab
nnoremap <silent> <leader>n :silent :tabnext<CR>
",p to go to next tab
nnoremap <silent> <leader>p :silent :tabprevious<CR>

I couldn't quite figure out why that could be. It does also happen when
switching to the tab for the 2nd and subsequent times.

Thanks, that's same issue as with ,m and columns dashboard. ,n is
"overloaded" by having other mappings that have same two letters plus a
third: ,ns and ,np and ,na . I'll get that fixed by removing the
overload, plus I have new functions that simplify moving between org
files. (The wait time you're seeing is consequence of 'timeout' and
'timeoutlen' settings, if you care.)

-- Herb

---

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