fix(profiling): do not clear thread-loop link too often #3668
Conversation
This file contains 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
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this.
Codecov Report
@@ Coverage Diff @@
## 1.x #3668 +/- ##
==========================================
- Coverage 78.11% 78.07% -0.05%
==========================================
Files 645 646 +1
Lines 50014 50054 +40
==========================================
+ Hits 39070 39081 +11
- Misses 10944 10973 +29
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
Kyle-Verhoog
approved these changes
May 4, 2022
releasenotes/notes/profiling-asyncio-less-clear-threads-33d3436ab76ea158.yaml
Show resolved
Hide resolved
P403n1x87
approved these changes
May 5, 2022
|
@Mergifyio backport 1.0 0.x 1.1 0.60 |
mergify bot
pushed a commit
that referenced
this pull request
May 12, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec)
mergify bot
pushed a commit
that referenced
this pull request
May 12, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec)
mergify bot
pushed a commit
that referenced
this pull request
May 12, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec)
mergify bot
pushed a commit
that referenced
this pull request
May 12, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec)
✅ Backports have been created
|
Kyle-Verhoog
pushed a commit
that referenced
this pull request
May 13, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec) Co-authored-by: Julien Danjou <julien@danjou.info> Co-authored-by: Gabriele N. Tornetta <P403n1x87@users.noreply.github.com>
Kyle-Verhoog
pushed a commit
that referenced
this pull request
May 13, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec) Co-authored-by: Julien Danjou <julien@danjou.info> Co-authored-by: Gabriele N. Tornetta <P403n1x87@users.noreply.github.com>
Kyle-Verhoog
pushed a commit
that referenced
this pull request
May 13, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec) Co-authored-by: Julien Danjou <julien@danjou.info>
Kyle-Verhoog
pushed a commit
that referenced
this pull request
May 13, 2022
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a task is resolved, which can be up to 100 times a second. This is way too much and we don't expect for the thread->loop mapping to change that often. Instead we often try to clear the mapping when a new loop is attached to a thread. In a regular application, this is the expected workflow: a thread appears and gets a new loop, so we clear the old ones. The worst case scenario would be an app spawning 100 threads with 100 loops and then not doing that ever again, which would make the profiler keep a reference on the 100 loops — until a new loop is attached, which if never, would kept the reference forever. Since this far from being a common pattern, it should be safe to switch to a simpler model like this. (cherry picked from commit f583fec) Co-authored-by: Julien Danjou <julien@danjou.info>
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.
The current code calls DdtraceProfilerEventLoopPolicy.clear_threads each time a
task is resolved, which can be up to 100 times a second. This is way too much
and we don't expect for the thread->loop mapping to change that often.
Instead we often try to clear the mapping when a new loop is attached to a
thread. In a regular application, this is the expected workflow: a thread
appears and gets a new loop, so we clear the old ones.
The worst case scenario would be an app spawning 100 threads with 100 loops and
then not doing that ever again, which would make the profiler keep a reference
on the 100 loops — until a new loop is attached, which if never, would kept the
reference forever.
Since this far from being a common pattern, it should be safe to switch to a
simpler model like this.