chore(api): further speed up ot3controller tests and add profiling #12132
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
pytest-profiling ( https://pypi.org/project/pytest-profiling/ ) is a pytest module that will automatically profile your tests for you if you so wish. If you add --profile to your test command, it will dump out top-ten calls by time, and it will dump more in-depth profiling data to `prof/` which can be interpreted with the python stdlib pstats/ module.
The OT3 gpio drivers have a sleep(1) in their init method. This isn't great, and will soon be removed - it was required for some nasty interactions between estop initialization and our canbus driver when it was initializing, and on later revs we don't need to handle the estop line like this - but in the meantime we can patch it out. This makes these tests take about a second in total instead of 80 seconds.
Codecov Report
@@ Coverage Diff @@
## edge #12132 +/- ##
==========================================
- Coverage 74.29% 74.29% -0.01%
==========================================
Files 2159 2159
Lines 59555 59554 -1
Branches 6093 6093
==========================================
- Hits 44248 44247 -1
Misses 13945 13945
Partials 1362 1362
Flags with carried forward coverage won't be shown. Click here to find out more.
|
In the cleanup of the thread manager, we were doing an asyncio.sleep(0.1) to spin the loop to make sure some classes cleaned up. Since then, we've learned that a 0-second sleep does the same thing. Changing the 0.1 to 0 should not present any changes in behavior (and if it does, they're in a cleanup method that is basically never run in prod) and doubles the speed of the tests in hardware_control.
We start and stop a lot of module servers, and polling to see whether they're started should be a lot faster now.
y3rsh
added a commit
that referenced
this pull request
Feb 13, 2023
* origin/edge: (31 commits) refactor(hardware): Update appropriate revision (#12130) fix(api): Fix accidental error on any PAPIv2.14 protocol (#12141) refactor(api): Allow homing after drop tip in engine core (#12124) fix(shared-data): remove newLocation and strategy from schemav6 (#12133) refactor(api): load pipette with useVirtualPipettes config option (#12117) chore(api): further speed up ot3controller tests and add profiling (#12132) docs(api): Settle in to leave Labware.default_magdeck_engage_height alone, for now (#12122) refactor(api): Improve error messages for JSONv6 and PAPIv2.14 protocols (#12131) refactor(robot-server): Note mistaken type in migration (#12126) chore(hardware): Remove docstring content checks (#12128) feat(hardware_control): Added firmware update mechanism for submodules (#12076) feat(app): remove feature flag for calibration dashboard and wizard updates (#12125) feat(app): Calibration dashboard wizard data invalidation (#12097) feat(hardware): support new revision values (#12111) feat(app): add Chip component (#12090) docs(api): Officially remove the `height` parameter of `MagneticModuleContext.engage()` (#12114) feat(system-server): add persistent UUID generation (#12123) feat(odd): add manual connection for a hidden network (#12033) feat(hardware): add progress output to subsystem firmware update process (#12059) refactor(api): Improve OT3 instrument calibration process (#11807) ...
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.
Some of our tests are really slow and it's a pain to figure out why! This PR
pytest-profiling is a pytest module that will automatically profile your tests for you if you
so wish. If you add --profile to your test command, it will dump out
top-ten calls by time, and it will dump more in-depth profiling data to
prof/which can be interpreted with the python stdlib pstats/ module.Also, add some fixes based on findings from profiling:
OT3 gpio sleep
The OT3 gpio drivers have a sleep(1) in their init method. This isn't
great, and will soon be removed - it was required for some nasty
interactions between estop initialization and our canbus driver when it
was initializing, and on later revs we don't need to handle the estop
line like this - but in the meantime we can patch it out.
This makes these tests take about a second in total instead of 80 seconds.
threadmanager cleanup
In the cleanup of the thread manager, we were doing an
asyncio.sleep(0.1) to spin the loop to make sure some classes cleaned
up. Since then, we've learned that a 0-second sleep does the same thing.
Changing the 0.1 to 0 should not present any changes in behavior (and if
it does, they're in a cleanup method that is basically never run in
prod) and doubles the speed of the tests in hardware_control. it makes those
tests take 9s instead of 25s.
Risk
None, tests only (and no test behavior changes, either)