Is mini.{statusline,hipatterns,cursorwords} more simple or performant?

[rieje]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.cursorword, mini.hipatterns, mini.statusline

Question

My favorite part of mini plugins is reading the comparison to other similar plugins section of the help page to quickly understand which of the alternatives might be more appropriate.

• mini.statusline: Is this more of a simple implementation of a working statusline or does it compare well to performant statusline plugins that might involves extra code to do stuff like caching, rely on autocommands instead of polling, etc.? I wanted to own custom statusline since it's not hard, but what is more involved is ensuring it stays performant (not just usable). What prompted my concern is the short-lived express_line statusline that was focused on performance/efficiency--for some reason it never took off and I don't see popular statusline plugins emphasizing features express_line implemented.

• Similarly, how does mini.hipatterns/mini.cursorwords compare to e.g. vim-illuminate (mostly the latter)? I assume mini.cursorwords uses just regex, while vim-illuminate takes on additional sources such as lsp and treesitter. I'm not sure what is different about using lsp/treesitter compared to regex though. Also curious if these plugins ever affect performance by nature of potentially many regex rules applied so frequently on the buffer.

Much appreciated.

[echasnovski]

That's an interesting question.

For 'mini.statusline' and 'mini.hipatterns' high performance was (and is) a design goal. The same goes for 'mini.cursorword', but slightly less so as it is more constrained by the implementation: it uses Vim's built-in word matching which I am pretty confident is quite optimized (at least it automatically highlights only visible instances, which is usually enough).

The actual problem is conducting proper benchmarking. There are at least two issues:

• Comparing different implementations that do roughly (or ideally exactly the same) set of actions. So for statusline it should be showing the same information (mode, git status, LSP status, etc.).
• Actually accounting for all the work that might be spread across different places. If it is not done during statusline evaluation, it doesn't mean it shouldn't count.

That said, I remember seeing 1.5-2 years ago a pretty rigorous speed comparison between statusline plugins present at that time. 'mini.statusline' was the fastest with the benchmark's author's statusline plugin being second. So I guess it is pretty fast compared to others :)

---

The timing of this is actually rather interesting. About a week or two ago I noticed that 'mini.statusline' doesn't cache diagnostic data on DiagnosticChanged event, which is probably a good reason to do. It is still pretty fast (at least on Neovim>=0.10), as it uses a dedicated fast vim.diagnostic.count(). Plus there will be a change in how file size is computed, which is both faster and more appropriate.

[echasnovski]

'mini.statusline' now even caches diagnostic data on DiagnosticChanged events. It allows skipping the call to vim.diagnostic.count() which is still an improvement.