Add ways to throttle thread creation #7
Closed
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.
This changes thread spawning to only spawn a single thread at a time. The
thread_wait_time
method allows you to specify a wait time before adding a thread to the pool which also delays spawning the next thread. The thread pool can now terminate before all worker threads have spawned. Aset_thread_target
method is added which allows you to tell the thread pool how many threads it should spawn. This thread target can change over time, but the thread pool will never remove threads once they are spawned.To test this I used a crate which depends on 101 dummy crates each with 16 empty functions. In rustc I used
set_thread_target(16)
before creatingTyCtxt
andset_thread_target(1)
after encoding metadata, which corresponds to the parts of rustc that takes advantage of the thread pool.thread_wait_time
was used in rustc like this:I then compiled this crate with
-Z threads=16
and-Z threads=1
with a parallel compiler to measure the overhead caused by spawning more threads. On Windows this was measured to 5% before this PR and 0.2% after. In a Linux VM I measured 85% overhead before this PR and 12% after. Most of the Linux improvement is likely due to reducing the thundering herd problem when the jobserver gives out a token, since less threads will be waiting on tokens.cc @cuviper @Mark-Simulacrum @alexcrichton