aboutsummaryrefslogtreecommitdiff
path: root/runtime/syntax/python.vim
diff options
context:
space:
mode:
authorLuna Razzaghipour <luna@xoria.org>2025-09-03 11:34:46 +1000
committerGitHub <noreply@github.com>2025-09-02 18:34:46 -0700
commitf9ce939bf53b84f7e6e4ecca3875dd0c378991db (patch)
treeb0a0d2fbea6e425c32d7b7a87b3e542f9706f719 /runtime/syntax/python.vim
parent1ae09bf54560ab9a060972012bcb0ebccff52978 (diff)
downloadrneovim-f9ce939bf53b84f7e6e4ecca3875dd0c378991db.tar.gz
rneovim-f9ce939bf53b84f7e6e4ecca3875dd0c378991db.tar.bz2
rneovim-f9ce939bf53b84f7e6e4ecca3875dd0c378991db.zip
perf: scheduler priority clamping on macOS #35488
Problem: All of Nvim’s threads are clamped to the Default QoS class. This means that Nvim is forced to compete for CPU time with compilers and other batch work, and is even prioritized beneath user-initiated work in GUI apps like e.g. file imports. This significantly harms responsiveness. Solution: Tell the kernel that the Nvim process takes part in rendering a UI. Implementation: Remove the process-wide QoS clamp. This doesn’t directly do anything to the main thread, but rather has the side-effect of letting the main thread run at its actual QoS (User Interactive QoS).
Diffstat (limited to 'runtime/syntax/python.vim')
0 files changed, 0 insertions, 0 deletions