-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: speed up to processing bluez passive data #221
Conversation
This is a ~5% speed up
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #221 +/- ##
==========================================
+ Coverage 82.67% 82.71% +0.03%
==========================================
Files 27 27
Lines 3221 3240 +19
Branches 668 671 +3
==========================================
+ Hits 2663 2680 +17
Misses 343 343
- Partials 215 217 +2
☔ View full report in Codecov by Sentry. |
This is a ~5% speed up
This is a ~5% speed up
This is a ~5% speed up
This is a ~5% speed up
This is a ~5% speed up
d542f25
to
0f1f22d
Compare
if not _expects_reply(msg): | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default was to always call send_reply when a reply wasn't expected it would just be thrown away. All that work for 6500 DeviceFound messages per minute and they are just discarded 🙈
Edit: after reviewing test data from multiple systems, this is avg of ~43% speed up
The previous design would create a response message and never send it if no reply was expected. Since the RSSI updates were all generating reply messages and throwing them away it was a significant CPU time use. By not generating the message we speed up getting data from the stream, and since everything has to wait for the data stream to get notifications / new GATT data it speeds up everything bluetooth for local adapters