Elm ports and Task scheduling under concurrent messages: controlling UI update latency

Answer

Elm 0.19 does not guarantee ordering or batching of messages that arrive from different ports in the same event‑loop turn; each port message creates its own external message that is queued and processed one after another. To keep the UI responsive you can coalesce rapid port traffic by keeping only the latest value and acting on it after a short delay (or on animation frames). To diagnose whether frame drops come from the Elm message queue or from browser rendering, record a Chrome DevTools performance profile and compare the length of JavaScript tasks (labeled “EventListener”/“Script”) with paint/compositing intervals.

Explanation (likely)

The observed latency during bursts is most likely caused by the Elm runtime invoking update once for each queued port message, because the runtime processes external messages sequentially on the JavaScript event loop. If each update does non‑trivial work, the UI thread blocks and frames are dropped.

Confirmed facts

• Elm’s runtime treats each incoming port message as a separate external message; ordering follows the order the JavaScript event loop delivers them, with no built‑in batching.
• Task values are turned into commands that are also queued as external messages; they have no priority mechanism.
• A “latest‑value” pattern (store the most recent payload and a timestamp, then act after a Time.delay or requestAnimationFrame via a port) guarantees at most one update per interval, discarding intermediate values.
• In Chrome DevTools, long JavaScript tasks indicate work in Elm’s update; long Paint/Render/Gpu intervals indicate browser‑side rendering work.

Steps to control latency

1. Add a field to your model that holds the latest payload and a timestamp, e.g. latest : Maybe ( Payload , Time ).
2. In the update handler for each port message, replace the stored payload with the new one and update the timestamp.
3. When the model changes, if there is no pending delay command, issue a Task.perform that waits a short interval (e.g. 16 ms for ~60 fps) using Time.delay or a port that requests requestAnimationFrame.
4. When the delay task completes, read the stored latest payload and apply the actual state change; discard any intermediate values that arrived while the delay was pending.
5. Optionally expose a port that logs timestamps before and after update to verify that bursts now produce fewer update calls.

How to measure the source of frame drops

1. Open Chrome DevTools → Performance → Record.
2. Trigger a burst of port messages (e.g., by sending many messages from a test harness).
3. Stop recording and examine the Main thread timeline.
4. If you see consecutive JavaScript blocks labeled “EventListener” or “Script” whose total duration exceeds the frame budget (~16 ms), the bottleneck is Elm’s message queue.
5. If JavaScript blocks are short but you see long “Paint”, “Render”, or “GPU” bars, the issue lies in browser rendering.