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:
Post a Comment