perf: is_executable calls fs_access for every file on every reload

Aperta Adatta ai principianti
  • Qualcosa non va?
#3,383 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
lua, neovim
Ambito
devtools, performance

Direzione di ricerca

Inizia individuando utils.is_executable e i due punti di chiamata descritti: la creazione di un nuovo FileNode ed Explorer:reload, dove lstat è già disponibile. Controlla come lo stat espone il tipo di file e i bit di esecuzione, quindi confronta il comportamento con i controlli fs_access esistenti. Il lavoro è completato quando i file regolari senza bit di esecuzione saltano quella chiamata di sistema, mentre directory, collegamenti e file eseguibili mantengono il comportamento attuale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

utils.is_executable calls vim.uv.fs_access(path, "X") for:

  • every new FileNode, and
  • every existing node on every Explorer:reload.

The node's lstat result is already available at both call sites.

Impact

fs_access costs 7.7µs per call vs 1.9µs for lstat. is_executable is about 11% of reload_explorer on a fully expanded 16.8k-node tree.

Proposed fix

Pass the existing stat into is_executable. A regular file with none of the user, group or other execute bits set can never pass access(X), even as root, so return false without the syscall. Files with execute bits, directories and links still use fs_access, happy to follow up with a PR soon.

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).

Lingua principale
Lua
Stelle
8.7k
Fork
642
Merge medio
1g 4m
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nvim-tree/nvim-tree.lua

Tutte le issue di nvim-tree/nvim-tree.lua

Issue simili

Altre issue su Lua

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.