Closed jweckman closed 1 year ago
Actually sorry i can not reproduce using the provided minimal config. I opened my entire home folder with over 100GB of data and cycled through quickly and it seemed that ripgrep was throttling at 30% CPU. I must have something oddly set up in my config.
I will track down what is causing it and come up with a suggestion for how to fix.
Issues was with either of these packages: use("nvim-telescope/telescope-fzy-native.nvim") use("nvim-telescope/telescope-rg.nvim")
Using only telescope-fzf-native.nvim avoids any problems for me.
Moral of the story seems to be that fzf-native.nvim has the best support and should be used. Closing
There is a bug with ripgrep introduced in #2440.
If you want to search with ripgrep, just use the old style arguments:
telescope.setup({
defaults = {
vimgrep_arguments = {
"rg",
"--color=never",
"--no-heading",
"--with-filename",
"--line-number",
"--column",
"--smart-case",
}
}
})
can confirm also have the bug, and I confirm it has to do with https://github.com/nvim-telescope/telescope.nvim/pull/2440 I suggest we reopen this issue
Can you guys try using rg --vimgrep
outside of neovim and see if it still causes an issue? I'm wondering if this is an rg
bug or a telescope bug.
@jamestrew, this is a telescope bug. And you can test it with the repository I mentioned in #2440.
Alright I'll look into this. I can create a PR to revert the --vimgrep
at least initially tomorrow.
np @jamestrew the temp fix works, I'll follow the repo to see when this gets fixed no rush, maybe just reopen this issue while it gets solved?
Please also fix nvim-telescope/telescope-live-grep-args.nvim if it also needs separate attention. live_grep without it is pretty useless to me as i have e.g. translation files that fill my entire telescope if i don't filter by file type/globs.
I dont think the revert fixes the core of the problem: Memory is not properly freed, for whatever reason.
I think an accurate description how memory ought to be managed and optional tracing with plenary.log is necessary besides manually running gc to get used memory. See https://github.com/nvim-telescope/telescope.nvim/issues/647#issuecomment-1532244593.
@matu3ba I'm not sure what the root of the issue is, but I do believe the revert will fix some causes / use cases.
The number of issues related to live_grep
or grep_string
performance/memory usage saw a noticeable increase since that --vimgrep
commit.
I'll continue to monitor issues and do a little digging myself.
Same issue for me, with a not so big JavaScript bundled file. Less than 500k. Navigating results for live_grep. tresitter disabled. macos with 16G ram died twice.
My config:
require("telescope").setup({
defaults = {
preview = {
treesitter = false, -- treesitter freezes on big files
},
},
})
https://github.com/eduardoarandah/nvimrc-public/blob/master/lua/plugins/telescope.lua
@eduardoarandah try this https://github.com/nvim-telescope/telescope.nvim/issues/2482#issuecomment-1528053505
I've seen problematic behaviour with rg alone as well: https://github.com/BurntSushi/ripgrep/issues/2505
The proposed fix is to add -j1
to the ripgrep args, maybe that should be included by default?
This seems to fix it for me:
nnoremap <leader>fg <cmd>lua require("telescope.builtin").live_grep({ additional_args = { "-j1" }})<CR>
@voidus thanks for linking that issue, that was very informative. I think a quick fix is still to simply revert back to the old vimgrep_arguments
settings (no using --vimgrep
) as I've done in #2488.
The recommendation to use --json
is interesting though. Separate issue (https://github.com/nvim-telescope/telescope.nvim/issues/2272) but I've briefly considered this as well. Switching over to --json
would require a good amount of rework though.
hello, having the issue with complete livegrep ram usage (100%) of ram on
release-1.3/neovim-0.9-d1c1bace
○ telescope.nvim Telescope
dir /home/coolcat/.local/share/lunarvim/site/pack/lazy/opt/telescope.nvim
url https://github.com/nvim-telescope/telescope.nvim
branch 0.1.x
commit 9de317b
readme README.md
help |telescope.theprimeagen|
help |telescope.nvim|
help |telescope.changelog|
@voidus suggestion helps, but would like to have correct behaviour out of the box
UPD: I was using LunarVim which is not being maintained now and it was locking plugins version. So my solution is to use something new. (updating, because maybe some other lunarvim users will face similar issue)
@Legomegger you're on a super old version of telescope. Just update it.
Description
I know there are a number of other performance related issues open related to live_grep using ripgrep, but i could not find instances of people reporting freezing of the entire OS making them lose all their work.
I know my use case is very crazy with say 10GB of code and i can see from journalctl that the ripgrep process is what causes the machine to run out of 16GB of RAM and 8GB of swap (fedora 38 with latest updates).
I can reproduce 100% if i go to a large directory and simply pless "k" to go through the live_grep results and i can see from my task manager that pressing "k" even once or twice makes the swap fill up and i have a frozen computer.
Running ripgrep on its own with the exact same scenario chugs along fine using all 8 cores and finishes without crashing. A single instance of ripgrep can handle itself no matter how heavy the load (100GB of code)
Would it be possible to maybe automatically slow things down a bit when a heavy load is detected to avoid freezing the operating system?
It seems like the memory issue is specifically related to cycling through results in the UI. I've had freezes happen even when there were 5 results in total and i quickly went through them.
My concrete question is then: Can the logic that is triggered when pressing "j" and "k" be adapted to refresh less or something when the queries get crazy? Maybe it could ask the OS how its doing before performing all the updates on every press of "j" or "k"?
Neovim version
Operating system and version
Fedora 38
Telescope version / branch / rev
latest 0.1.x
checkhealth telescope
Steps to reproduce
Expected behavior
Either slow down or kill neovim instead of freezing the OS.
Actual behavior
Frozen operating system (Fedora 38)
Also had the same issues on Fedora 36
Minimal config