perf: Filters:custom calls getcwd for every file, even with no custom filters
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- lua, neovim
- Domain
- performance
Research direction
Start with lua/nvim-tree/explorer/filters.lua, especially Filters:custom and Filters:prepare; the issue identifies the repeated vim.uv.cwd() call and proposes resolving it once per directory only when custom patterns exist. Check the existing filtering tests and add coverage for empty and nonempty custom patterns. Done when filtering behavior stays the same and the unnecessary cwd calls are avoided; pull request #3387 is already open for this issue.
Written by the indexing model from the issue text.
Description
Problem
Filters:custom calls vim.uv.cwd() for every file that gets scanned, via utils.path_relative(path, vim.uv.cwd()) (lua/nvim-tree/explorer/filters.lua:180). This happens even when filters.custom is empty, the default, so the result is never used.
getcwd is slow on some platforms: about 61µs per call on macOS.
Impact (profile on master)
| Operation | Share of time on this line |
|---|---|
api.tree.expand_all() |
33% |
Explorer:reload_explorer() |
42% |
Proposed fix
- Return early from
Filters:customwhen there are no custom patterns. - Resolve the cwd once per directory in
Filters:prepare, and only when there are custom patterns.
Filtering behaviour stays the same.
Happy to follow up with a PR as soon as I get some time.
Environment: macOS, Nvim v0.13.0-dev, LuaJIT 2.1. Test repo: 16.8k files and folders, 3.1k git status entries (modified, untracked, ignored). Measured headless with vim.uv.hrtime() and the LuaJIT profiler (jit.p).
- Dominant language
- Lua
- Stars
- 8.7k
- Forks
- 642
- Avg merge
- 1d 4m
- Merged PRs (30d)
- 11
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nvim-tree/nvim-tree.lua
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
nvim-tree/nvim-tree.lua#3383 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
nvim-tree/nvim-tree.lua#3382 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
nvim-tree/nvim-tree.lua#3381 ·
Maintainers usually reply within 1 day
-
Use vim.Option getters and setters instead of directly settingPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nvim-tree/nvim-tree.lua#3357 · 1 comment ·
Maintainers usually reply within 1 day
-
Migrate To vim.packOpendocumentation PR please
Difficulty 1/5 Under an hour Newbie friendliness 65/100
nvim-tree/nvim-tree.lua#3179 · 6 comments ·
Maintainers usually reply within 1 day
All issues in nvim-tree/nvim-tree.lua
Similar issues
-
bug confirmed discord guide:tyrs-watch locale:enUS navigation v0.3.2
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
fitzforge/polestar#855 · 1 comment ·
Maintainers usually reply within 1 day
-
Bug
Difficulty 1/5 Under an hour Newbie friendliness 91/100
DennisRas/WeeklyKnowledge#164 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
perf: <BS> runs regex compares for rules that can never deletePossibly taken @hood claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
windwp/nvim-autopairs#555 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 2 days