Decrease event loop latency by binding time.monotonic to loop.time directly

[bdraco]

I've been running this for a while with good results. Not expecting an side effects since its calling the exact same path under the hood without the python method call wrapper.

Proposed change

This is a small improvement to decrease event loop latency. While the original goal was to reduce Bluetooth connection time latency, everything using asyncio is a bit more responsive as a result.

base_events.py is almost always the top file in profiles since _run_once is there. This change eliminated at least 10% of the run time in that file, ~13.8% in when profiling as the time call is made upwards of ~30000 times per minute on systems with 4 bluetooth remotes/local adapters. The python time method call that wrapped time.monotonic, is the most frequently called non built-in method on all my production systems, and it was more expensive than the actual call to time.monotonic since time.monotonic is implemented as a built-in/cext.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[bdraco]

It looks like async_fire_time_changed might be off by a microsecond. Will investigate more tomorrow

[bdraco]

Looks like it's always been a bit off but it worked before because the run time of the python code was long enough that time moved forward enough between when the time call was made and when the system call/vdso call was made. Now it's too fast and it can fail

[bdraco]

We need to add clock_resolution to fix async_fire_time_changed

https://github.com/python/cpython/blob/ee40b3e20d9b8d62a9b36b777dff42db1e9049d5/Lib/asyncio/base_events.py#L400

[bdraco]

freezegun is also a problem since it patches time.monotonic

[balloob]

Let's give this a try. I would expect any issues to be mainly related to testing as you've experienced in this PR.

Do you think there is an opportunity to upstream this? Or would the JIT work in Py3.12 and beyond make this obsolete?

[bdraco]

Let's give this a try. I would expect any issues to be mainly related to testing as you've experienced in this PR.

Do you think there is an opportunity to upstream this? Or would the JIT work in Py3.12 and beyond make this obsolete?

I've been trying to upstream things that have near 0% risk like the selector changes (all of them are in now). For us changing the test suite a bit usually doesn't cause too many downstream issues, but for cpython itself, it could be a lot bigger issue. This change likely has a much larger benefit for our use-cases vs the general asyncio user since we tend to read a lot (30000 is just what I see on my systems, I've seen users with 100000+ but I think they are outliers) of small packets (esphome, bluetooth, shelly, zeroconf, ssdp, etc). Also, I think the work in Py3.13+ (maybe Py3.14+ actually depending on how things shake out) will make it less impactful.

[bdraco]

thanks!