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 <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEdUs1yWc9P06ZfTCA5DoLRZRN_zO4t_vCMhdkL32Rb2PA%40mail.gmail.com.
