Thursday, January 7, 2021

Re: do plugins affect performance?

I was thinking the same thing: unless a plugin
has expensive autocommands that trigger often, but do nothing (CursorHold, for example), the only time performance hit should be upon initial startup when it's loaded.

It is possible that a plugin defines mappings with ambiguity and that introduces a timeout for Vim to figure out which mapping to use, but that delay isn't caused by the hardware not being able to keep up. I occasionally get mapping collisions in new plugins that conflict with unused plugins or unused parts of plugins, which would be a good reason to only keep the plugins you actually use. 

Salman

On Thu, Jan 7, 2021, 13:30 Charles Campbell <campbell@drchip.org> wrote:
I agree with gevisz: a plugin could have an impact on performance even
if not used. Just imagine that there's a busy wait loop that fires up
when the plugin is loaded -- it would just hog the machine (well, at
least a core).

Nonetheless, mostly what plugins do upon startup is:

   define functions
   define various mappings, commands

Vim, of course, does have to determine whether or not a given sequence
of symbols invokes a command, function, or mapping. There are a number
of ways to do this; some are log-m (m=qty characters in the string,
n=qty of strings), so adding in extra mappings, commands, and functions
should be negligible cost in time.

So, I would not expect unused plugins to exact a performance cost.

Regards,
Chip Campbell

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEdUs1yWc9P06ZfTCA5DoLRZRN_zO4t_vCMhdkL32Rb2PA%40mail.gmail.com.

No comments: