Performance issues

[xaljer]

When I enable this plugin and type words, coc's auto completion become very slow and broken. After this, cursor moving also get lag. When I disable it, every thing works well.

[p00f]

I know, there are performance issues. I'm not experienced enough to fix them. I'm still trying to find the solution

[xaljer]

I test on latest coc.nvim, neovim and ts-rainbow, this issue still exist.

[p00f]

I tested this properly, the slowdown is only when completion is enabled. I should've tested this the first time oof

[xaljer]

It looks like still slowdown many operations like move or edit in my environment.

[fgheng]

The same problems occurred while I edit a python file, but other file is ok.

[tramhao]

for me, the slow down happens in lua file. I found in lsp.log

pack/packer/opt/nvim-lspconfig/lua/lspconfig/configs.lua:57 ]     "        The language server sumneko_lua
incorrectly triggers a registerCapability handler\n        despite dynamicRegistration set to false. Please report upstream.\n

don't know if it's relevant. I'm using nvim-lspconfig, treesitter, completion-nvim and ts-rainbow.

[p00f]

i don't think it is relevant

[p00f]

Guys it should be much better now (not completely fixed), please update and test

[p00f]

watch nvim-treesitter/nvim-treesitter#879

[rodamaral]

This is still an issue. An example that makes it noticeable is editing this file with and without this plugin, specially in insert mode.

[p00f]

Unfortunately currently I have no clue how to fix this

[runiq]

This is still an issue. An example that makes it noticeable is editing this file with and without this plugin, specially in insert mode.

That's quite a pathological example, don't you think…?

[p00f]

1800 pairs hehe

[rodamaral]

This is still an issue. An example that makes it noticeable is editing this file with and without this plugin, specially in insert mode.

That's quite a pathological example, don't you think…?

Yes, just to make the issue clear. Sometimes the CPU usage stays at 100% for several seconds.
But the issue exists in normal files, but the effects appear randomly at least to me.

[matu3ba]

I do expierence the issue on a almost pure lua setup (using clangd) on editing a 500 LOC c++ file.
This happens on editing comments or code without typing any brackets. Probably some indexing with updates on a bracket insertion could fix this.

@p00f Can you recommend a luajit profiler to identify the source? C-type languages are painful without colored brackets.

EDIT: Or applying it every few seconds.

[p00f]

See the ones mentioned here nvim-lua/wishlist#4

Yeah the idea is very good, I don't need to run everything whenever text changes

[p00f]

I don't have time rn, I'll look into profiling after a week or so (I have zero prior experience). @matu3ba you can have a go!

[p00f]

nvim-ts-rainbow/lua/rainbow/internal.lua

Line 92 in 3557b7b

vim.api.nvim_buf_attach(bufnr, false, {on_lines = attachf}) --do it on every change

Currently it happens on every change

https://neovim.io/doc/user/api.html#nvim_buf_attach()

[matu3ba]

@p00f

The solution should distinguish between modes: In insertion mode one wants to redraw, if any bracket was inserted.
In all other modes the solution is fine, because it should immediately redraw bracket colors. Do you know, how fast/slow getting the mode is?

If that wont be enough, we could also make it faster coloring by indexing and reverse iterating scopes to find what parts to redraw. But that would be notable complexity.

[p00f]

idk how slow that is, vim.api.nvim_get_mode() returns the mode

[p00f]

color_no takes up 48%, maybe we can store nodewise numbers in a table?

[p00f]

I can try writing queries for just brackets and use query:iter_captures() directly

[p00f]

Can you guys try out the query_iter_captures branch?

[p00f]

@rodamaral i tested your test.tsx again, it is much more usable now on the query_iter_captures branch (still slow though, but i didn't notice anything when typing random garbage quickly inside a clojure string)

[ttys3]

the plugin cuased nvim stuck on CPU 100%

related issue: neovim/neovim#14037 (comment)

lot's of something like below if I use kill nvim:

Error executing vim.schedule lua callback: /usr/local/share/nvim/runtime/lua/vim/treesitter/query.lua:135: bad argument #1 to 'get_node_text' (string expected, got nil)
Error executing vim.schedule lua callback: /usr/local/share/nvim/runtime/lua/vim/treesitter/query.lua:135: bad argument #1 to 'get_node_text' (string expected, got nil)

... lots ....

[p00f]

@ mjlbach got nvim-treesitter removed and problem still exists

This plugin won't work at all without nvim-treesitter though, it's a module for nvim-treesitter.

nvim-ts-rainbow/lua/rainbow.lua

Line 2 in 35e971a

local configs = require("nvim-treesitter.configs")

nvim-ts-rainbow/lua/rainbow.lua

Line 1 in 35e971a

local queries = require("nvim-treesitter.query")

nvim-ts-rainbow/lua/rainbow/internal.lua

Line 1 in 35e971a

local queries = require("nvim-treesitter.query")

(sorry for the tag mjlbach, I edited it)

(Now that you are here, can you test the query_iter_captures branch and see if it improves performance. You'll have to write a small query yourself for the language you're testing)?

[mjlbach]

(sorry for the tag mjlbach, I edited it)

Not quickly enough ❤️

[mjlbach]

Just for the record I did not suggest removing tree-sitter lol

[ttys3]

@p00f that comment is not accurate. please check the last two comments

[ttys3]

@p00f got nvim-treesitter removed and problem still exists. it is ref to:
if I got nvim-treesitter removed, the problem CPU goes 100% still exists.

but the CPU will goes down very qucikly.

[matu3ba]

@p00f If I use packer.nvim with

-- treesitter
  use { 'nvim-treesitter/nvim-treesitter', run = ':TSUpdate' }
  use { 'nvim-treesitter/nvim-treesitter-refactor' } --TODO setup
  use { 'nvim-treesitter/playground' } --inspecting treesitter data: :TSPlaygroundToggl


  use { 'p00f/nvim-ts-rainbow', branch = 'query_iter_captures' } --TODO performance problem --

I cant get my c++ file colorized to investigate.

However, it works with the master branch.
treesitter config:

require'nvim-treesitter.configs'.setup {
  ensure_installed = "maintained",
  highlight = {
    enable = true,
  },
  rainbow = {
    enable = true,
  },
}

What am I missing?

PS: Sorry for the missing reply yesterday.

[p00f]

oh yeah i forgot to tell you, you have to write queries for each filetype. Just save ["{" "}" "[" "]" "(" ")"] @paren into <plugin-directory>/queries/cpp/parens.scm

[p00f]

nvm i did that since it had to be done anyway, please update and try

[matu3ba]

@p00f It has much better performance, which is sufficient for 1k LOC and 110 brackets.
grep -o '{' FILE | wc -l and find FILE -type f -exec wc -l {} + | sort -rn.

The delay difference with and without rainbow is still noticable with and without rainbow, but the file size/number of brackets has not a noticable effect anymore.
If one does not type very fast, it is fine to use.

I am more concerned about the lsp regressions (could also be clangd). Either cmake creates wrong compile_commands.json or clangd gives up on my codebase to find the files. Nope, just the vim plugin gave up or regressed or I changed settings.

[mjlbach]

There have been no lsp regressions. If anything, it should be faster now.

[p00f]

Great, I'll merge the new branch after writing queries for all languages 😄 . I'll still keep this open

[p00f]

merged #11

[rodamaral]

Performance is much better now, even in my previous file. Thanks for the efforts!

[TornaxO7]

I'm using nvim-compe and it's lagging for me. If I set rainbow = {enable=false} than all laggs disappeared.

[matu3ba]

@TornaxO7 What is the size of the file? You can run my command for all bracket types:
grep -o '{' FILE | wc -l on the biggest file in your project find FILE -type f -exec wc -l {} + | sort -rn.

Are you on latest master neovim with updated treesitter? There were breaking changes in treesitter, which may not have stabilized.

Does :checkhealth for your language say that everything is fine? Your grammar might be not updated or bad.

[TornaxO7]

Does :checkhealth for your language say that everything is fine? Your grammar might be not updated or bad.

Currently I'm coding in C and this is in :checkhealth:

  - c              ✓ ✓ ✓ ✓ 

grep -o '{' FILE | wc -l

Output:

41

find FILE -type f -exec wc -l {} + | sort -rn.

output:

610 main.c

My plugins should be up to date. I executed :PlugUpdate but I'm still getting this performance issue when setting rainbow.enable = true.

[TornaxO7]

Here's a little live demo:

Video.mp4

As you can see, if I turn off rainbow neovim runs smoother.

[p00f]

Please update and test, imo this can be closed

(I might have broken some queries so please try to test as many languages as you can 🙂 )

[p00f]

@Gelio @rmagatti i take the reactions to mean this has improved?

[Gelio]

@Gelio @rmagatti i take the reactions to mean this has improved?

From my perspective, yes! I no longer have input lags when working on a ~1k LOC file. I haven't tested it extensively, but IMO looks good now

[TornaxO7]

For me, it's faster now as well! Thank you for the fix :)

[p00f]

Nice! Thanks to theHamsta and tzachar