ci: fix ui thread starvation in benchmarks #2009
Merged
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
Maxing out CPU with a hot while loop also prevented the test runner app from being able to query the accessibility system to hit the stop button. This causes lots of retries and eventual failures or timeouts in other areas, and the tests to run a long time in general. Instead of having a button press stop the benchmark and contending for time on the main run loop, just remove the start/stop buttons and start when the view controller appears, and set a 15 minute delay to stop the benchmarks. Then the test runner queries the text field for results as usual.
indragiek
approved these changes
Jul 27, 2022
kevinrenskers
added a commit
that referenced
this pull request
Aug 1, 2022
* master: ci: benchmarking and profile generation improvements (#2022) release: 7.23.0 fix: Bad merge on CHANGELOG.md (#2020) fix: Log empty samples instead of collecting stacks for idle threads (#2013) fix: Handle failure to read thread priority gracefully (#2015) fix: Remove logging that could occur while a thread is suspended (#2014) fix: Use constant for max thread name size instead of magic number (#2012) Disable flaky tesDefaultMaxEnvelopesConcurrent (#2018) Fix build failure in unit tests (#2019) Fix address sanitizer compilation error (#1996) fix: Sauce labs iPhone 13 pro iOS version feat: Add transaction to baggage and trace headers (#1992) ci: fix ui thread starvation in benchmarks (#2009) fix: Add more descriptive deprecation message for enableProfiling (#2011) feat: Add sampling configuration for profiling (#2004) fix log message option name (#2006) meta: add armcknight as a codeowner (#2008) release: 7.22.0 fix: Disable broken LaunchUITests to unblock release (#2003) # Conflicts: # Samples/iOS-Swift/iOS-Swift/ViewControllers/PerformanceViewController.swift
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.
Maxing out CPU with a hot while loop also prevented the test runner app from
being able to query the accessibility system to hit the stop button. This causes
lots of retries and eventual failures or timeouts in other areas, and the tests
to run a long time in general.
Instead of having a button press stop the benchmark and contending for time on
the main run loop, just remove the start/stop buttons and start when the view
controller appears, and set a 15 second delay to stop the benchmarks. Then the
test runner queries the text field for results as usual. Removing the steps needed
to press the start and stop buttons also saves time.
#skip-changelog