[Bug]: Performance Issue - bufferline Consumes Excessive CPU Time

[apollo1321]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I've observed that when I open a substantial number of buffers (around 30), Neovim becomes unresponsive. Upon closing all the hidden buffers, performance improves significantly. To diagnose the issue, I created a flamegraph, which revealed that "bufferline" is consuming 70% processing time, which is more than all my ~30 other plugins combined together.

What did you expect to happen?

I expect "bufferline" to be lightweight and efficient, ideally consuming around 1% of CPU time, similar to how "lualine" performs.

Config

local bufferline = require("bufferline")

bufferline.setup({
  options = {
    numbers = "none",
    offsets = {
      {
        filetype = "NvimTree",
        text = "NvimTree",
        highlight = "Directory",
        text_align = "center",
        separator = true
      }
    },
    style_preset = bufferline.style_preset.minimal,
  },
  highlights = {
    fill = {
      bg = spec.bg0
    },
    background = {
      fg = syn.comment,
      bg = spec.bg0
    },
    tab = {
      fg = spec.bg3,
      bg = spec.bg0
    },
    tab_selected = {
      fg = spec.bg0,
      bg = spec.bg0
    },
    tab_separator = {
      fg = spec.diag.info,
      bg = spec.bg0
    },
    tab_separator_selected = {
      fg = spec.diag.info,
      bg = spec.bg1
    },
    tab_close = {
      fg = spec.diag.error,
      bg = spec.bg0
    },
    close_button = {
      fg = spec.diag.error,
      bg = spec.bg0
    },
    close_button_visible = {
      fg = spec.diag.error,
      bg = spec.bg0
    },
    close_button_selected = {
      fg = spec.diag.error,
      bg = spec.bg1
    },
    buffer_visible = {
      fg = spec.fg1,
      bg = spec.bg0
    },
    buffer_selected = {
      fg = spec.fg0,
      bg = spec.bg1,
      bold = true,
      italic = true,
    },
    error = {
      fg = spec.diag.error,
      bg = spec.diag.error
    },
    error_diagnostic = {
      fg = spec.diag.error,
      bg = spec.diag.error
    },
    modified = {
      fg = spec.diag.hint,
      bg = spec.bg0
    },
    modified_visible = {
      fg = spec.diag.hint,
      bg = spec.bg0
    },
    modified_selected = {
      fg = spec.diag.hint,
      bg = spec.bg1
    },
    separator_selected = {
      fg = spec.diag.info,
      bg = spec.bg1
    },
    separator_visible = {
      fg = spec.diag.info,
      bg = spec.bg0
    },
    separator = {
      fg = spec.diag.info,
      bg = spec.bg0
    },
    indicator_selected = {
      fg = spec.bg1,
      bg = spec.bg1
    },
    offset_separator = {
      fg = spec.bg0,
      bg = spec.bg1
    },
  },
})

Additional Information

...

commit

No response

[akinsho]

@apollo1321 if you are willing to dig in and provide suggestions then PRs very much welcome. Given the mountain of never ending feature requests for this plugin I would say it's definitely not as lightweight as it could be and if you're looking for a truly minimal solution you can probably write your own tabline without too much effort, alternatively I think heirline.nvim is probably more minimal but I don't know for certain. Lastly I believe lualine actually has a tabline feature so you could just use that.

There's probably dozens of optimisations I could make to this plugin but given that it's one of several plugins I maintain that I frankly have increasingly less time to maintain especially given that community contributions are very low it's very much a best effort when there is time which is rare.

[apollo1321]

Thank you, @akinsho, for your response and advice. I greatly appreciate the hard work and time you dedicate to maintaining this plugin along with many others.

Just to provide more context, I was using the plugin at commit 81820cac7c85e51e4cf179f8a66d13dbf7b032d9.

Following your suggestion, I disabled the bufferline plugin and used Neovim without it for several days. The difference in responsiveness has been very noticeable; Neovim has become significantly more pleasant and efficient to use.

Considering my experience, I wonder if other users might also be facing similar performance issues without realizing the cause. To help the community, I would suggest adding a note in the README regarding this potential performance impact for users managing a large number of buffers. This could save others from the confusion I initially felt, thinking the lags were due to external factors.

[adinhodovic]

Thank you, @akinsho, for your response and advice. I greatly appreciate the hard work and time you dedicate to maintaining this plugin along with many others.

Just to provide more context, I was using the plugin at commit 81820cac7c85e51e4cf179f8a66d13dbf7b032d9.

Following your suggestion, I disabled the bufferline plugin and used Neovim without it for several days. The difference in responsiveness has been very noticeable; Neovim has become significantly more pleasant and efficient to use.

Considering my experience, I wonder if other users might also be facing similar performance issues without realizing the cause. To help the community, I would suggest adding a note in the README regarding this potential performance impact for users managing a large number of buffers. This could save others from the confusion I initially felt, thinking the lags were due to external factors.

Tracking this issue. For what it's worth enabling the LSP functionality with Bufferline causes markdown files to stop scrolling, crash and consume 100% CPU. Without bufferline or without the Bufferline LSP feature being enabled it runs fine.

[akinsho]

There was a PR a few weeks ago to start updating the diagnostic indicators when nvim updates them. This could be causing bufferline to rerender too aggressively. If anyone has the time to track down that commit and revert it to see if it's the cause that could help a bunch

[hinell]

I've tackled down some serious issues with diagnostic updates.

Checkout the PR down below. I would appreciate much if you could test it and tell the difference: gh pr checkout 1010

• fix(diagnostics): limit amount of diagnostics processed improving performance #1010