perf: renderer highlights via vim.hl.range are slow on large trees
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- lua
- Domain
- frontend, performance
Research direction
Start in Renderer:render_hl and trace how it applies single-line byte ranges and priorities. Compare the existing vim.hl.range calls with nvim_buf_set_extmark using vim.hl.priorities.user; verify the resulting highlights are identical and benchmark rendering on a large tree. Done means the direct extmark calls preserve the same ranges, priorities, and appearance while reducing rendering time.
Written by the indexing model from the issue text.
Description
Problem
Renderer:render_hl applies every highlight of every line with vim.hl.range. That function is generic: on each call it switches buffer context with vim._with, calls col('$') twice and calls getregionpos. nvim-tree's ranges are always single-line byte ranges, so none of that work is needed.
Impact
| µs per highlight | |
|---|---|
vim.hl.range |
6.1 |
nvim_buf_set_extmark |
0.74 |
At 16.8k visible lines, render_hl is about 50% of Renderer:draw() (620ms) and about 15% of reload_explorer.
Proposed fix
Call nvim_buf_set_extmark directly with the same ranges and the same priority (vim.hl.priorities.user). The highlights produced are identical. Happy to provide a PR for this ofc.
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
-
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
-
perf: Filters:custom calls getcwd for every file, even with no custom filtersPossibly taken @hood claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
nvim-tree/nvim-tree.lua#3386 ·
Maintainers usually reply within 1 day
All issues in nvim-tree/nvim-tree.lua
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Balatro-Multiplayer/BalatroMultiplayerPvP#620 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Balatro-Multiplayer/BalatroMultiplayerAPI#55 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
silverbulletmd/silverbullet#2231 ·
Maintainers usually reply within 2 days