mirror of
https://github.com/esphome/esphome.git
synced 2026-09-17 18:18:43 +00:00
J. Nick Koston
f9ad090bf9
On Xtensa under default -mserialize-volatile, GCC emits a memw before every volatile load. esphome_lwip_socket_has_data() is called once per socket per main-loop iteration (one for the listening socket in APIServer::loop and one per connected client in APIConnection::loop), making per-call memw a measurable cost on the idle path. Replace the per-call memw with a single std::atomic_thread_fence (memory_order_acquire) at the top of Application::loop. The fence pairs with the TCP/IP thread's existing SYS_ARCH_UNPROTECT release on rcvevent. The wake path (xTaskNotifyGive in the lwip event_callback hook, ulTaskNotifyTake at the bottom of the loop) is independent of rcvevent visibility and is non-losing, so writes that land between the fence and sleep are picked up by the next iteration. Gated on ESPHOME_THREAD_MULTI_ATOMICS so that BK72xx (which lacks LDREX/STREX and is built without libatomic) keeps the original volatile load path. ESP32, RTL87xx and LN882x get the optimization; ESP8266, RP2040 and host use the socket_ready_fd fallback and are unaffected. Disassembly (ESP32, gatetrigger): APIServer::loop -8 B, APIConnection ::loop -5 B; loop_task gains one memw for the fence. Net per idle iteration with N clients: save N memw on ready paths, add 1 for the fence (savings scale with client count and other Socket::ready callers like AsyncClient and CaptivePortal DNS).
