As a developer who primarily works with API gateways and middleware, I'm accustomed to instrumenting backend services with detailed metrics. However, I find myself somewhat at a loss when the "service" in question is my own Neovim instance, and the instrumentation is lacking. My current environment is plagued by periodic freezes and a general sense of sluggishness during startup, particularly after introducing a new set of LSP and tree-sitter related plugins.
My plugin list is substantial and leans heavily towards system integration:
* `nvim-lspconfig` + `nvim-cmp` + numerous language servers (sumneko_lua, tsserver, etc.)
* `telescope.nvim` with several extensions
* `nvim-tree.lua`
* `which-key.nvim`
* `gitsigns.nvim`
* `neo-tree.nvim`
* `toggleterm.nvim`
* `plenary.nvim` (as a dependency for many)
* Several custom webhook notification plugins I've been prototyping.
Given this context, I wish to begin a systematic, profiling-driven approach to diagnosing the issues. My instinct from backend work is to reach for both memory and CPU metrics simultaneously, but I recognize that desktop tooling (like `htop` or Process Explorer) provides a different granularity and that the nature of a text editor's performance issues might favor checking one metric first.
My question, therefore, is methodological: For a novice to profiling Neovim (or VSCode, or any similar editor with a plugin ecosystem), what is the most effective *first* metric to isolate?
* Should I prioritize **memory usage** (RSS/VIRT), as a high or climbing memory footprint could indicate a leak in a plugin, which would eventually lead to swap usage and general slowdown?
* Or should I prioritize **CPU utilization**, as a consistently high CPU—even at idle—might point to a busy loop in a plugin's logic (e.g., a poorly implemented file watcher or status line updater) that is directly causing input latency?
I am operating on macOS Ventura 13.4, but I'm interested in principles that apply cross-platform. I am comfortable with terminal tools and can follow technical instructions. My goal is to establish a baseline diagnostic step: a single, simplest metric to check (via `top`, `ps`, `:checkhealth` in nvim, or a dedicated plugin) that will most likely provide the highest signal-to-noise ratio for identifying a problematic plugin interaction. From there, I can drill down with more granular tools.
null