Reduce lag in mappings that frequently switch between normal and insert mode

Question

As a concrete (although hyperbolic) example:

nnoremap , a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>aX<esc>

This mapping will take a bit to actually type out an "X" (at least in my underpowered Celeron. You may have to up the number of a<esc> if you have a better CPU).

I have dozens of plugins installed, some that can make a huge amount of operations running possibly hundreds of lines of code, but all of them execute in a fraction of the time, so I was a bit surprised to find out that, out of all of these operations, changing modes is what made neovim chug.

Am I missing something? Is there a way to speed up this type of mapping?

Answer 1

It would help if you would give a more concrete example of what you need to do that takes a long time. For me your example is instantaneous, even if I make it several times as long.

However, to answer your question, it might help to use <c-o> in insert mode to run one normal mode command and then Vim automatically switches back to insert mode.

You can also read registers into your cursor position without switching out of insert mode using <c-r> and then the register name. You can even read in an expression this way using the = register. For example:

nmap , atest<c-r>=1*2*3*4<cr>test<c-o>otest

Another thing you can do is set the 'lazyredraw' option, which prevents Vim from redrawing the screen while running macros. Although it doesn't seem to make any difference for me with your example.

Answer 2

Credits to D. Ben Knoble and Heptite for the performance tips.

---

The biggest culprit ended up being InsertEnter and InsertLeave autocommands. By tracking them down and removing them, there was a significant performance improvement.

The remaining bit of lag was solved by "set lazyredraw", which stops vim from redrawing the screen while running macros.

---

Note: There's still a lesser (but noticeable) delay if I run the mapping a higher amount of times, say 100 (with qa,q100@a), although this is very much acceptable. Nonetheless, any tips to further improve performance are appreciated.