Packer.nvim: Profiling and performance tuning

[wbthomason]

Most of the computational cost of packer goes to running git, etc. However, it would be worthwhile to profile major components like manage, compile, the generated lazy-loader code (in some representative cases), etc. to see if there's anywhere we can improve performance.

It would also be worthwhile to see if the loading time of packer can be decreased, i.e. by making modules lighter to require or only conditionally requiring modules. Probably worth seeing how much time goes to requires to start with, though.

[Th3Whit3Wolf]

Some runtime performance could be had load on filetype autocmds were replaced with putting those commands into ~/.local/share/nvim/site/ftplugin or ~/.config/nvim/ftplugin to take advantage of neovim's builtin autoloading.

[wbthomason]

Yeah, that's a good idea/something I'd been thinking about.

I think I'd like to write "lazy-load compilation 2.0", which would (1) use ftplugin files for filetype loads, (2) put the auto-generated Lua in its own module to make things a bit simpler, and (3) if the user sets a config value indicating that they only use a single, requireable file for plugin specification (rather than splitting their specifications across multiple files or embedding Lua in Vimscript), can detect when the config has changed and trigger an automatic recompile.