Repository navigation
chore(submodule): bump nyanpasu-utils to cap runtime worker threads - #446
Merged
Merged
Conversation
The shared runtime that nyanpasu-service and the app run on started one worker per logical CPU. nyanpasu-utils now caps it at four, which keeps the thread and memory cost flat on many-core machines without the stalls a single worker shows when a task blocks.
|
Review changes with |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
nyanpasu_utils::runtime::default_runtime()started one worker per logical CPU.nyanpasu-serviceruns on that runtime throughruntime::block_on, and the app hands it to Tauri. nyanpasu-utils#200 caps it:When
available_parallelism()fails, the runtime starts one worker.The app was measured on Windows 11 with 32 logical CPUs (details in nyanpasu-utils#200). Above four workers, more workers added threads and private memory without improving timer lateness or CPU time. With one worker, a single blocking operation stalled the runtime for up to seconds.
TOKIO_WORKER_THREADSno longer affects this runtime, because the explicitworker_threadstakes precedence over it. Nothing here sets it.The submodule moves from 7d923f8 to
mainplus the change. The only other difference is renovate's lockfile bumps to the crate's ownCargo.lock, which this workspace does not use. This workspace'sCargo.lockis unchanged.Downstream
clash-nyanpasu will follow as a draft PR stacked on this one.
Checks
cargo clippy --all-targets --all-features --lockedpassed. The only warnings are ones already onmain.cargo test -p nyanpasu-utils --lib runtimepassed:default_runtime_caps_its_workers.Not tested
nyanpasu-servicewas not run or measured with the cap.