search

nanozuki / tabby.nvim

A declarative, highly configurable, and neovim style tabline plugin. Use your nvim tabs as a workspace multiplexer!
MIT License
607 stars 21 forks source link

feat: max_refresh_ms to limit maximum call to render() #146

Closed ilan-schemoul closed 3 months ago

nanozuki commented 4 months ago

Very glad to see a PR!

But what time do you encounter a performance problem? In My testing, tabby.nvim renders the tab line very fast, less than 0.1ms per time. And the neovim wouldn't render the tab line too much.

Since neovim wouldn't render the tabline too much, if we missed one timing to render the tabline, the tabline would display too much delay. If we want to reduce re-rendering, we should set the timeout and render at the end of the timeout.

Last, there are some conflicts in PR.

ilan-schemoul commented 4 months ago

To answer your first point (I'll see later about other points): profiling show tabline is what most costly. I don't know why but sometimes it's called many times in a row (I can for example use vim.notify to see a message for every render). I think it's just because I have a somewhat complex logic in my function. I already tried to optimize this logic as much possible with deferred update and caching (for example to determine if I'm in the middle of a rebase, to change the colors of the tab) https://github.com/ilan-schemoul/nvim-config/blob/main/nvim/lua/plugins/tabby.lua

nanozuki commented 3 months ago

Sorry for being late; I have been busy these past weeks. I read and tried your config, but I can't find an obvious problem. Can you make a minimal reproduction config and tell me how to measure this problem?

In another way. If you have a heavy function in tabline's rendering, you can make this cache mechanism for that function alone. Limited the total tabline render my cause display delay, as I said before. If you like, I can also add a pre-render hook, to help you archive this.