INNER CODE UNIT · Python

_async_preload_ml_modules

3dg1luk43/ha_washdata · custom_components/ha_washdata/__init__.py:479

async def _async_preload_ml_modules(hass: HomeAssistant) -> None:
    """Import the ML modules off the event loop (issue #328).

    ``ml.engine.resolve_scorer`` / ``resolve_regressor`` are called from the event
    loop (live matching, end detection, quality gating), and Home Assistant flags
    the lazy ``importlib.import_module`` they used to do there as a blocking call.
    Warming the module cache once per setup in the import executor makes every
    later resolution a ``sys.modules`` lookup. Best effort: a failure here only
    means ML stays inert, so it must never block setup.

    Two things matter for startup time here (issue #408), because
    ``hass.import_executor`` is ``max_workers=1`` and is shared with every other
    integration importing during startup, so an awaited job on it costs however
    deep that queue happens to be - measured at 35-95 s in real user
    diagnostics, against ~1 ms of actual work:

    1. The job is coalesced onto ONE shared future for the whole HA instance.
       ``preload_models()`` is idempotent, so a second job per config entry

View source record →

📰 Research Paper
Loading…
⏳ Fetching content…